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(57) ABSTRACT 

The present invention provides a solution to the needs 
described above through a system and processe to be used in 
the mortgage industry for combining an Loan Application 
System with an automated Compliance Engine used for 
generating and monitoring a set of required procedures 
involved in moving and tracking a mortgage loan through 
one or more of the steps of 'originate', 'approve', 'close', 
'fund', and 'ship'. The automated compliance engine itself 
is a system and method for automatically generating a set of 
required tasks for use in managing the mortgage loan 
process, including tasks required by applicably federal or 
state law. The system of the present invention automatically 
couples the regulatory compliance information engine and a 
task management system required to process loans and 
provides methods for integrating the Automate Compliance 
Engine technology with any third party's loan processing 
software. 
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Have you declared bankruptcy in the last 7 years? 
Oyes Cno 

if so what kind of bankruptcy was filed? 

if yes, what yaar and month was the bankwptcy filed? 

Year : [ j Month : lJon_@ 

was bankruptcy duo to financial mismanagement? 
Oyes Cno 

Have you had a home foreclosed or given a deed in lieu in the last 7 years? 
Oyes Ono 
if yes, what year? 
Year : I I Month : | Jem |jH 

Do you have any outstanding liens or judgements? 



How many times have you been past due on any mortgage in the last 24 months? 
How many times have you been past due on any other debt in the last 24 months? 

m 

How many times have you been past due on any mortgage In the last 12 months? 
EI 

How many times have you been past due on any other debt in the last 12 months? 
EI 

How long do you expect to be in the home? 
Citizenship Status 

b_ w 
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TSSi b^iw * Instructions: The following are the loan programs that tit the 
«lt »* option*.' criteria you entered on the previous pages. Please click on the loan 

program title that best meets Your needs. 



- t5 Year Fixed Rate. Expanded Credit. Full Dccnmenlatinn 

8.625% -0.750 10.137% $137.00 S1 ,500.00 
Sub-Prime. 15 Year FixBd Rata. Full Documanlatinn 



$13j500.00 

11.300% 0.G00 12721% $156.00 $1,500.00 J13.500.00 
15 Year Fixed Rate. 103% ITV 

14.000% 0.000 15.218% $190.00 $1,500.00 $13,500.00 
3% DWP, 30 Year Fixed, fate 

8.875% 1.E75 10.498% $113.00 $1,500.00 $13,500.00 
3% Down. 30 Year Fixed Rata 

8.875% 1.875 10.496% $113.00 $1,500.00 $13,500.00 

30 Year Fix ed Rate, Expanded Credit. Full Documentatio n 

8.625% -0.750 3.902% $111.00 $1,500.00 $13,500.00 

8.750% -0.125 10.113% $112.00 $1,500.00 $13500.00 
30 Year Fixed Rata 103% I TV 

9.000% -0.500 9.627% $120.00 $1,500.00 $13,500.00 
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Loan Program Selected: 

15 Year Fixed Rate, Expanded Credit, Full Documentation 



Loan Amount J13.SOO.00 
Down Payment: $1,500.00 
Hale: B.625% 



Principal 4 Interest: 5134.00 
Taxes 8. Insurance 517.00 
Mortgage Ins: $3.00 
Total Monthly Payment: $154.25 



Origination Fee (HUD #301) 
Points Paid/Discount 
Appraisal Fes (HUD #303) 
Underwriting Fee (HUD #312) 
Administration Fee (HUD #315) 
Settlement or Closing Fee (HUD #1101) 
Title Insurance (HUD #1108) 
Recording/Filing Fees (HUD #1201) 
Survey (HUD #1301) 

Per diem interest (HUD #901) 15 days @ $3.19 
Total: 



$135.00 
(11013) 



$595.00 

$250.00 
$36.00 

$250.00 
$47.05 
$2,157.60 
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Frank Schmuk 

Current Street Address |l234AnyStrast j~ 

Current City | AnyTcwne ~ j~ 

Current Slate, Zip |ak"1I , ,12345 I " 

°*"/R<>nt EOwn ORenr 

Length oftae at this address Ye3rs ^Z}, Months E~> 
If less than 2 years complete the following information 





®Ovm ORent 




Years I"" - 1 


Months 1 1 


1 1 



Previous address 2 (include 
city, state, zip) 

°<™IR«* <?Own ORent 

Length of time at this address Ye8rs r— ] „ f- 
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Subject property zip 
# 0elete Number of units 

HZZ1- 

Occupancy Type 
I Owner Occupied 

How long do you expect to be in the borne? 
Property Type 

[Single Fami^Detached |« 
Building Status 
[grating ||f 

If acondo or PUD • whst are estimated HOA fees/month? 




Figure 25 
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loan guarantee? 




(1) What type of property did you own? 




Figure 28 
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Figure 34 
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FIG. 35 
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TRANSACTION SERVICE PROVIDER GATEWAY 4400 
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FIG. 36 
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Figure 37 
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l^OStep 4: Borrower Updates and Loan Processing 
35% of loan orgination fee 

Task 

• Review and explain undetwriting decision with borrower 0> Loan Originator 

• Review and explain other closing conditions to the O Real Estate Broker 

boiro ** r , , . L „ „ n Mortgage Processing 

o Review and explain the Good Faith Estimate with 
borrower 

o Review and explain the Truth in Lending statement 

with borrower 
o Review and explain other federal and state 

disclosures with borrower 

• Get borrower's signature on documents 

• Collect the mandatory conditions from the borrower 

o Collect the income information (paystubs, W2 and 

tax records as required) 
o Collect the bank statements from the borrower 
o Collect the Insurance Binder information 

• Forward all conditions to processing 

• Review and explain the results of the Title Report 

• Review and explain the results of the Appraisal 

• Review and explain the results of the Flood Certification 

• Provide regular status updates to the borrower 

• Order the Flood Certification 

• Order the Survey (as required) 

09 Step 5: Closing 
15% of loan orgination fee 
Task 

• Review and authorize the Clear to Close document from 
processing 

• Lock the interest rate for the loan 

• Coordinate closing with borrower and title company. 

• Attend closing 



<?' Loan Originator 
O Real Estate Broker 
O Mortgage Processing Center 



^ Go Back 

Figure 40 



Go Forward * 
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INTERFACE SYSTEM FOR A MORTGAGE LOAN 
ORIGINATOR COMPLIANCE ENGINE 

RELATED APPLICATIONS 
[0001] This application is a continuation-in-part to non- 
provisional co-pending application Ser. No. 09/645,217 
Filed Aug. 24, 2000, titled "Method and Apparatus for a 
Mortgage Loan Originator compliance Engine." This appli- 
cation is filed in accordance with 37 CFR § 1.53 (b)(2) and 
is also related to the following co-pending non-provisional 
utility applications: 

[0002] Ser. No. 09/645,799 filed Aug. 24, 2000, titled 
"Method and Apparatus for a Mortgage Loan Man- 
agement System." 

[0003] Ser. No. 09/645,775 Filed Aug. 24, 2000, 
titled "Method and Apparatus for a Mortgage Loan 
Origination Gateway"; 

[0004] Ser. No. 09/645,796 Filed Aug. 24, 2000, 
titled "Method and Apparatus for Verification of a 
Qualified Mortgage Loan Originator"; 

[0005] Ser. No. 09/645,800 Filed Aug. 24, 2000, 
tilled "Method and Apparatus for a Mortgage I-oan 
Task Flow Process"; 

[0006] Ser. No. 09/645,798 Filed Aug. 24, 2000, 
titled "Method and Apparatus for a Mortgage Loan 
Process Interaction Gateway"; 

[0007] Ser. No. 09/645,801 Filed Aug. 24, 2000, 
titled "Method and Apparatus for a Mortgage Loan 
Transaction Service Provider Gateway"; and 

[0008] Ser. No. filed Feb. 13, 2001, titled 

"Method and Apparatus for an Advanced Speech 
Recognition Portal for a Mortgage Loan Manage- 

COPYRIGHT NOTICE 
[0009] A portion of this patent document contains material 
which is subject to copyright protection. The copyright 
owner has no objection to the facsimile reproduction by 
anyone of the patent document or the patent disclosure, as it 
appears in the Patent and Trademark Office patent file or 
records, but otherwise reserves all copyright rights whatso- 



TECHNICAL FIELD 
[0010] The present invention relates to the general field of 
computers, telecommunications, and computer and Internet 
related systems. More specifically the invention relates to 
systems and processes to be used in the mortgage industry 
for combining a customer Loan Application System with an 
automated Compliance Engine used for generating and 
monitoring a set of required procedures involved in moving 
and tracking a mortgage loan through one or more of the 
steps of 'originate', 'approve', 'close', 'fund', and 'ship'. 

BACKGROUND 
[0011] Bank and other lending companies in the mortgage 
loan industry have developed automated loan application 
processing systems to make the loan application process 
more efficient and more centrally controlled. Such systems 



are typically programmed to generate some of the tasks 
associated with a mortgage loan application such as request- 
ing an appraisal, evaluating the loan contract and application 
data, authorizing a loan, tracking the closing activities and 
completing the financial disposition of the loan. Such sys- 
tems generally contain no regulatory oversight or control of 
the tasks performed. Such oversight and control is assumed. 

[0012] There is a need for an automated system for 
managing the processing of mortgage loan applications, 
wherein the identification of the loan originator, his/her 
location and the location of the property which is the subject 
of the loan, determine the Federal and State mortgage loan 
laws and regulations as well as the professional guidelines 
which govern the loan transaction, and wherein the auto- 
mated system uses the specific loan regulations to determine 
the tasks required to complete a loan transaction, including 
tasks required by applicably federal or state law, provide the 
set of required tasks to lenders and other interested parties, 
record the completion of the set of tasks, and if requested by 
a lender, to use the set of tasks internally to drive the flow 
of the automated mortgage loan process to completion. 
Furthermore there is a need for such a regulatory compliance 
system which can easily be coupled to existing loan appli- 
cation processing systems. 

[0013] The Federal laws and regulations in question are 
basically those outlined in the Real Estate Settlement Pro- 
cedures Act (RESPA) and the Federal Housing and Urban 
Development's (HUD's) implementing Regulation X. The 
State regulations in question are those State specific regu- 
lations and implementing instructions that serve a similar 
purpose, relating to Lender payments to Mortgage Brokers 
and other settlement service providers. RESPA is the federal 
law implemented by IIUD's Regulation X, to protect home 
buyers from excess costs and confusion when securing a 
home mortgage loan. Among other federal laws, the Truth in 
Lending Act ("TILA") and the Equal Credit Opportunity Act 
("ECOA") impact the mortgage loan process. Under the 
TILA, certain credit related disclosures are required to be 
made to the borrower prior to the consummation nf a 
mortgage loan transaction, so that the borrower understands 
the total cost of the loan. 

[0014] The ECOA and its implementing regulation, 
Regulation B, were enacted and promulgated to require that 
lenders make credit equally available to all creditworthy 
borrowers without regard to race, color, religion, national 
origin, sex, marital status, age, receipt of public assistance or 
the fact that the borrower in good faith exercised any right 
under the Federal Cousumer Credit Protection Act. In addi- 
tion to the prohibition against discrimination, the ECOA and 
Regulation B also contain, among others, requirements 
regarding ihe provision of appraisal reports, evaluation of 
applications, spousal signatures, and the provision of 
adverse action notices. 

[0015] Regarding state laws, most jurisdictions have 
enacted licensing statutes that may require real estate sales 
professionals, builders, financial institutions/lenders and 
mortgage brokers to obtain a license and satisfy various 
other financial, educational and operational requirements. 
Most jurisdictions also have enacted laws that impose, 
among others, requirements regarding the types of fees that 
may be charged to a consumer in connection with a mort- 
gage loan transaction and the persons entitled to receive 
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such fees, as well as certain jurisdiction-specific disclosures 
that must be provided to the consumer. 

[0016] There is a need for a system to facilitate the 
application of all of these laws and regulations ("regula- 
tions") in an efficient and systematic manner during the 
course of a mortgage loan transaction by using the telecom- 
munications and computing facilities available to the market 
today. 

[0017] While some state laws are more restrictive, RESPA 
allows a licensed real estate professional to receive com- 
pensation for originating a mortgage loan only if that real 
estate professional provides goods or facilities or performs 
services that are necessary for the origination of the loan and 
that are separate and distinct from any services the real estate 
professional provides incident to the sale of the property that 
secures the mortgage loan. Moreover the mortgage loan 
process is labor intensive, error prone and time consuming 
for all parties concerned, making it diiEcult for a real estate 
professional to track the services he or she provided to 
satisfy RESPA and state requirements to justify receiving 
compensation. 

[0018] The demand for fairness and equity, as well as an 
increasingly competitive lending environment, was the rea- 
son why RESPA was passed and now requires a greater level 
of sophistication on the part of the lending community. 
Furthermore as indicated above, increasing oversight on the 
part of governments and regulatory agencies have required 
increased levels of sophistication in the traditional borrower- 
lender relationship. While these oversight demands are 
generally considered to be a benefit to the borrower-lender 
relationship, it is, nonetheless a burden to all parties, and 
significant increases in both time and cost are accrued to the 
process. As well, protective regulations added by the lending 
community under whose umbrella the industry operates, 
further protract the process of 'doing business'. These 
regulations and 'rules' governing the mortgage process 
permit those in the loan origination role to receive a fee for 
services rendered when the applicable rules are followed, as 
well as penalties and loss of fees for non-compliance. For 
example, RESPA has criminal penalties wherein a violator 
can go to jail for up to a year. 

[0019] In the past, attempts have been made to automate 
some parts of the mortgage loan process. For example, U.S. 
Pat. No. 5,995,947 issued Nov. 30. 1999 to IMX Mortgage 
Exchange titled "Interactive Mortgage and loan information 
and real-time trading system" provides a system and method 
for trading loans wherein a transaction server maintains a 
database of pending loan applications and their statuses, and 
wherein each party to the loan (broker, lender) can search 
and modify the database consistent with their role in the 
transaction. However this system focuses on only one facet 
of the loan process itself. Other parts of the loan process are 
addressed in U.S. Pat. No. 5,966,700 issued Oct. 12, 1999 to 
Federal Home T/ian Rank of Chicago, titled "Management 
System for Risk Sharing of Mortgage Pools" is a system 
wherein a mortgage originator (bank, savings & loan, etc.) 
and a funding institution (Federal Home Loan Bank, etc.) 
agree to assume certain risks for the mortgage by entering 
into a credit agreement having an overall credit enhance- 
ment value, and wherein the system calculates and records 
the allocation of mortgage interest and credit risk between 
them. This system functions after a mortgage has been 



issued which is outside of applicants' present system. 
Another recently issued patent related to mortgage loans is 
U.S. Pat. No. 5,991,745 issued Nov. 23, 1999 to Fannie Mae, 
titled "Reverse Mortgage Loan Calculation System and 
Process", which is a payment calculation system related to 
loans that the borrower is generally not required to repay 
until the security properly is sold. Still another is U.S. Pat. 
No. 5,940,812 issued Aug. 17, 1999 to LoanMarket 
Resources, LLC titled "Apparatus & Method for Automati- 
cally Matching a Best Available Loan to a Potential Bor- 
rower via Global Telecommunications Network" teaches a 
system for matching loan requests (and related credit data) 
to lenders (with related eligibility criteria) in order to 
facilitate such loans whether they be for automobile pur- 
chases or whatever. Similarly, other U.S. Patents teach 
methods for real time loan approval (U.S. Pat. No. 5,870, 
721), methods for Lender direct credit evaluation and loan 
processing (U.S. Pat. Nos. 6,029,149; 5,930,776; and 5,611, 
052); and methods for keeping track of loans, loan histories, 
leases and pertinent data related thereto (U.S. Pat. No: 
4,774,664). 

[0020] Inherent in most property transactions, especially 
those involving a mortgage, are other elements which, as 
suggested before, serve to protect the interests of all con- 
cerned parties, but which unnecessarily protract the under- 
writing process. These generally include at least the follow- 
ing: a processing procedure and fee to originate the loan 
application, a title search to discover any encumbrances on 
the property such as liens, overdue taxes, etc., a credit check 
on the borrower of record to determine the credit-worthiness 
of the individual, a verification of employment which speaks 
to the individual's ability to repay the loan, a property 
survey, where such is dictated by local laws, an appraisal to 
determine if the property value secures the lender's invest- 
ment, application for various insurances such as flood, 
earthquake, or other insurance as local law and custom 
requires, the loan application itself, and other such applica- 
tions, searches, and discoveries, as local laws dictate. In 
addition to the aforementioned, an income to debt ratio is 
established to help select the most appropriate loan pro- 
gram^) consistent with the lender's policy and the borrow- 
er's requirements. As indicated above, many lenders have 
implemented automated Loan application processing sys- 
tems which attempt to keep track of some or all of these 

[0021] Of equal importance in the process is the distribu- 
tion of service fees and commissions associated with real 
estate mortgage transactions. The timeliness and accuracy of 
transactions can adversely affect the payment of various 
agents or workers involved in the process. Furthermore, 
because of the almost casual connection between the parties 
to the transaction, coupled with heretofore rigid definitions 
of each worker's responsibility, creative solutions to the 
aforementioned problems were not forthcoming, and little 
could be done to remedy these problems. Personal interven- 
tion on the part of agents or other workers could help, but 
weren't part of the scope of the transaction, were unreliable, 
and were differentially applied, often in consideration of 
such elements as the wealth or prestige of the borrower, the 
value of the property, personal friendships, or other less 
tangible factors. 

[0022] Many of the agents or workers participating in the 
transaction bear a limited portion of the responsibility for the 
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transaction. Employment verification, title searches, and the 
like, are often of fixed duration and required effort with 
mortgages falling within a broad value range. As such, these 
workers enjoy a steady, regulated income flow. It falls 
however, to the real estate agent to invest time on an 
open-ended basis to accomplish a sale. In this instance, the 
commission is often fixed by industry convention or statute, 
and the Real estate sales professional typically doesn't enjoy 
the benefit of serving as both listing and buying agent, which 
might net a full commission. More typically, the agent must 
make a 50 /so split with another agent or agency. Adding 
injury to this significant commission reduction is the typical 
requirement that the remaining commission balance be split, 
usually <%>, with the Real estate sales professional's parent 
agency. It is common for a Real estate sales professional, 
having invested many hours over a period or weeks or 
months, to realize a modest 1-2% of the selling price of the 
property. Given this scenario, it is expected that a Real estate 
sales professional will focus on opportunities which will 
bear fruit faster, and leave the longer-term prospects alone, 
even though they have a similar reward and are of equal 
value in the eyes of the respective buyers and sellers. 
[0023] The current state of the art simply does not provide 
a means whereby the real estate sales professional, or any 
other agent or worker, may participate in the other portions 
of the monetary flow, beyond that which is historically 
common to their respective industries. 
[0024] While there are a number of developing systems, as 
mentioned above, for automated lender .selection and loan 
tracking, it is clear that a need exists for an automated 
system based upon a database of federal, state and local rules 
and regulations, which can be used to identify, tor a given 
loan transaction, the set of tasks required to process and 
complete the loan transaction, including tasks required by 
applicably federal or state law, and to track the set of tasks 
during the process itself to reasonably assure that compli- 
ance with these rules and regulations can be reported, or 
alternatively, that compliance task completion may be traced 
to the entity reporting completion. There is a further need to 
automatically attach the regulatory compliance information 
with a task management system required to process loans 
and to provide methods for integrating the Compliance 
Engine technology with any third party loan application 
processing software. 

SUMMARY OF THE INVENTION 

[0025] The present invention provides a solution to the 
needs described above through a system and process to bo 
used in the mortgage industry for combining a lender's Loan 
Application System with an automated Compliance Engine 
used for generating and monitoring a set of required proce- 
dures involved in moving and tracking a mortgage loan 
through one or more of the steps of 'originate', 'approve', 
'close', 'fund', and 'ship'. The automated compliance 
engine itself is a system and method for automatically 
generating a set of required tasks for use in managing the 
mortgage loan process, including tasks required by applica- 
bly federal or state law. The system of the present invention 
automatically couples the regulatory compliance informa- 
tion engine and a task management system required to 
process loans and provides methods for integrating the 
Automate Compliance Engine technology with any third 
party's loan processing software. 



[0026] 'lhe automated system of the present invention uses 
the Federal, State, local and professional regulations and 
requirements and implementing instructions to generate a 
plurality of tasks which can be used to control and drive the 
process of handling a mortgage loan application to comple- 
tion and settlement in accordance with these regulations . 
Mortgage loan requestors may specify that the system will 
generate the plurality of required tasks, including tasks 
required by applicably federal or state law, provide the 
plurality of required tasks to the requester for his execution, 
including tasks required by applicably federal or state law, 
and monitor the completion of all required tasks so as to 
provide a completion certificate to the requestor. Alterna- 
tively, mortgage loan requestors may specify that the auto- 
mated system will generate the plurality of required tasks, 
including tasks required by applicably federal or state law, 
will manage and control the execution of the required tasks, 
and monitor the completion of all required tasks so as to 
provide a completion certificate to the requestor. 

[0027] The invention allows loan originators to enter loan 
applications and comprises a platform to allow other entities 
to underwrite the loan (that is, this invention is not a loan 
approval system, but can use any lender's loan approval 
system) but which provides the means to control and drive 
the mortgage transaction to closing by means of a compli- 
ance system which contains a rules engine built around the 
required Federal and State regulations and which tracks and 
records every step in the process to provide a record of 
completion for Federal and State regulators. The invention 
was designed to provide mechanisms for use to assure that 
loan originators meet and exceed federal, state, local and 
professional laws governing the relations between real estate 
sales and mortgage lending activities. 

[0028] A computer implemented method is disclosed for 
facilitating processing of a mortgage loan application 
wherein the system receives a request to process a mortgage 
loan from a third party loan processing system; generates a 
plurality of tasks, the tasks comprising actions required to 
process the mortgage loan, and including tasks required by 
applicable federal and/or state law; and distributes one or 
more of the required tasks to the third party loan processing 
system for execution of the tasks. The" method further 
provides an act of monitoring the completion of the plurality 
of tasks whereby a report of completion of all required tasks 
can be generated. 

[0029] An apparatus is disclosed for automated processing 
of mortgage loans which has a compliance engine with 
communications devices for receiving a request to process a 
mortgage loan from a client loan processing system; the 
compliance engine having logic devices programmed to 
generate a plurality of tasks required to process the loan, 
wherein the tasks are made up of actions which are required 
for a specific mortgage loan by various legal rules and 
regulations; and wherein the compliance engine has logic 
devices programmed to distribute the plurality of tasks to the 
client loan processing system. 

[0030] Also disclosed is a server node in a network which 
is responsive to a request to process a loan from a third party 
loan processing system by generating a plurality of tasks 
which are required to process the requested loan, including 
tasks required by applicably federal or state law, and for 
distributing the plurality of tasks to persons who are quali- 
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lied to perform the tasks. Also disclosed are mechanisms in 
the server node for monitoring the completion of the plu- 
rality of tasks related to a given loan and for generating 
reports and completion certificates associated with the 
actions related to the given loan. 

[0031] Also, a computer program stored on a computer 
readable medium or carrier wave is disclosed having com- 
puter code mechanisms for receiving a loan request from a 
client loan processing system; for generating a plurality of 
tasks required to process the loan, including tasks required 
by applicably federal or state law, and distributing the 
plurality of tasks to the client loan processing system for 
execution. Additional code mechanisms are disclosed which 
monitor the completion of the plurality of tasks and when all 
tasks are completed can issue various reports and comple- 
tion certificates. 

[0032] Still other embodiments of the present invention 
will become apparent to those skilled in the art from the 
following detailed description, wherein is shown and 
described only the embodiments of the invention by way of 
illustration of the best modes contemplated for carrying out 
the invention. As will be realized, the invention is capable of 
modification in various obvious aspects, all without depart- 
ing from the spirit and scope of the present invention. 
Accordingly, the drawings and detailed description are to be 
regarded as illustrative in nature and not restrictive. 

DESCRIPTION OF THE DRAWINGS 

[0033] The features and advantages of the system and 
method of the present invention will be apparent from the 
following description in which: 

[0034] FIG. 1 illustrates a typical configuration of Internet 
connected systems representative of the preferred embodi- 
ment of the present invention. 

[0035] FIG. 2 illustrates a typical general purpose com- 
puter system of the type representative of the preferred 
embodiment. 

[0036] FIG. 3 illustrates the business model which 
encompasses the present invention. 
[0037] FIGS. 4A & 4B illustrate a functional flow chart of 
a preferred embodiment of the system. 
[0038] FIG. 4C illustrates a configuration of an embodi- 
ment of the system which contains the invention. 

[0039] FIG. 4D illustrates exemplary functions of the 
Compliance Engine. 

[0040] FIG. 5 illustrates a configuration of an alternative 
embodiment of the system which contains the invention. 
[0041] FIG. 6 is a flow chart depicting the process Map 
and Workflow Definition for a New Loan. 
[0042] FIGS. 7-30 illustrate exemplary screenshots for the 
system embodying the present invention. 
[0043] FIG. 31 illustrates an exemplary Internet configu- 
ration showing the hardware and software systems used in 
an embodiment at this time. 

[0044] FIG. 32 illustrates another exemplary Internet con- 
figuration showing the hardware and software systems used 
in an embodiment at this time. 



[0045] FIG. 33 illustrates an exemplary embodiment of 
the Input gateway module. 

[0046] FIG. 34 illustrates an exemplary relationship of 
various system elements with the GHR sub-system. 
[0047] FIG. 35 illustrates an exemplary embodiment of 
the "task maintenance & status reporting" gateway. 
[0048] FIG. 36 illustrates a preferred embodiment of the 
"transaction service provider" gateway. 
[0049] FIGS. 37-41 depict additional screen shots of the 
system embodying the invention, showing an exemplary set 
of tasks required to complete a loan. 

DETAILED DESCRIPTION 
[0050] 'JTie present invention provides a solution to the 
needs described above through a system and process to be 
used in the mortgage industry for combining a client Loan 
Application System with an automated Compliance Engine 
used for generating and monitoring a set of required proce- 
dures involved in moving and tracking a mortgage loan 
through one or more of the steps of 'originate', 'approve', 
'close', 'fund', and 'ship'. The automated compliance 
engine itself is a system and method for automatically 
generating a set of required tasks for use in managing the 
mortgage loan process, including tasks required by applica- 
bly federal or state law. The system of the present invention 
automatically couples the regulatory compliance informa- 
tion engine and a task management system required to 
process loans and provides methods for integrating the 
Automate Compliance Engine technology with any third 
party's loan processing software. 

[0051] The heart of various embodiments of the present 
invention is a module designated an Automated Compliance 
Engine (the "Compliance Engine") which is designed to 
maintain and use a rules-based loan compliance database to 
generate the set of tasks required to be performed to com- 
plete and close a specific mortgage loan transaction. This 
Compliance Engine is described in more detail below. 
Similarly, the method of the interface between the compli- 
ance engine and a client loan application processing system 
is described in more detail below. However, we now 
describe a general overview of a preferred embodiment of 
the invention. 

[0052] (1) General Overview 

[0053] All mortgage loans will be originated through the 
applicants (OnePipeLine.com) website. In the future, web- 
sites other than Applicant's will be used to originate loans 
that will interface with the compliance engine. The technol- 
ogy used as part of the system currently is able to interface 
with many other industry standard software programs to 
make the exchange and flow of data easy and accurate. 
[0054] The system is predominantly web-enabled, which 
extends its use to all industry professionals connected to the 
Internet. The system contains the Compliance Engine that 
applies Federal, State, Local, and profession based filters to 
each loan application and each Loan Originator to create a 
combined task list that defines a custom workflow process 
for every transaction originated through the System and 
Program, which forms the basis for monitoring the steps and 
procedures required for a specific loan transaction in order 
to provide a completion report for the specific mortgage 
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loan. The rules applied to each new mortgage loan applica- 
tion will determine who is permitted or required to perform 
which services in the loan origination process under the 
Program and who will receive fair market compensation for 
services actually performed. The System then creates a 
record of the actual workflow. The list, as a composite of 
compensation or origination tasks and required tasks, is 
represented as a 'task list', and may optionally be presented 
to a subscriber client through an API. 

[0055] In a preferred embodiment of the invention, the 
automatic compliance engine's processes and workflow are 
integrated with the client's loan origination system (LOS) in 
a manner which results in a compliant loan. The resulting 
system, which is the product of the client's LOS and the 
compliance engine and its interface, provides comprehen- 
sive workflow, forms and disclosures, closing requirements, 
tracking, a compliance report, a compliance certificate of 
guarantee. The net result is a product which is a lender 
branded business to business system, thereby opening a new 
channel with which to compensate third party originators. 
[0056] In a preferred embodiment, the main features of the 
union of a client LOS and the compliance engine arc: 

[0057] 1) a XML based programming interface that 
allows for specific loan and compliance data to be 
shared between the compliance engine and the cli- 
ent's consumer direct web-based LOS. The XML 
messages are delivered back and forth between the 
compliance engine system and the client LOS using 
HTTPS POST events. 

[0058] 2) a scries of branded web pages — hosted by 
applicants— that control and manage the delivery of 
the consultative and prequalification compliance 

[0059] The development of this XML based interfaced 
system usually requires a business process review of the 
client's LOS with recommendations of changes and 
enhancements necessary to move them to a compliant third 
party loan origination system. These changes encompass 
technology, web page content, and business processes that 
need to be performed, typically by the client's employees. 
[0060] (2) Detailed Description 

[0061] In an embodiment of the combined client/lender 
LOS and applicants compliance engine ("the System"), the 
Borrower and Loan Originator work together throughout the 
loan origination process. Once a Borrower decides to work 
with a Loan Originator on the System, the System will have 
the Borrower and Loan Originator answer typical financial 
and property questions concerning the Borrower. The 
answers to these questions will allow the System to pre- 
qualify the Borrower for a loan and offer appropriate loan 
program options to the Borrower, and authenticate the loan 
Originator in the system. For example, when an agent 
originator is ready to begin the loan process, he/she must be 
authenticated through applicant's credentialing database. 
The primary mechanism for this to occur is through an XML 
API developed by applicant and implemented in the client 
LOS. 

[0062] It is necessary for the agent to review the process 
with their client, pre-qualify their client as to the amount of 
home and loan amount they can afford, and to disclose 



certain information to their clients via business disclosure 
forms. When this part of the transaction is completed, a loan 
instance is created using the compliance engine and the 
appropriate tasks are marked as complete. Additionally, the 
compliance engine system generates an ACS ID# which is a 
unique transaction identifier, which becomes part of the 
Loan Record which will be created using the Client's LOS. 
This identifier can either be manually entered by the agent 
or programmatically delivered from the applicants system to 
the lender system using the designed XML API. The client 
will use this unique identifier to track and report back to 
applicants compliance engine system on the progress of the 
loan through the rest of the process. 

[0063] At this point in the process, the agent is directed 
back into the client's consumer direct LOS (which has beeu 
reviewed and modified for third party loan origination). 
Once the System makes this information available to the 
Borrower and Loan Originator, the Borrower will be able to 
choose to make a formal mortgage loan application on-line 
through the Loan Originator. 

[0064] After the agent has worked through the Client's 
loan application system (at the point the application is 
submitted for processing) The compliance engine system 
needs to receive a subset of the collected loan data in order 
to update the compliance record in the compliance engine 
system. The compliance engine will use that data to update 
the task list and recheck the compliance of the loan appli- 
cation. The data coming back to Applicants will be delivered 
either programmatically using the XML API or through a 
manual web page interface that the client's loan processors 
will use. 

[0065] (Loan Status Updates): At five specific times dur- 
ing the processing and underwriting process, the compliance 
engine system needs to be made aware of changes in the loan 
status. The compliance engine system notifies the third party 
originator so they can keep the borrower up to date and the 
loan progress. The client's LOS can notify the compliance 
engine system of these status changes using the XML API or 
the client can alter it's business process to have the loan 
processor come to the compliance engine system web site, 
and manually make the changes to the loan status. 

[0066] Closing & Certification Data Transfer: When the 
loan is ready to go to closing, the client needs to receive 
from the compliance engine system key information per- 
taining to closing instructions that must be followed to 
ensure the HUD1 document is prepared correctly. 

[0067] During the processing of the loan, certain data may 
have changed which would impact the compliance of the 
loan. For this reason, the client must reconfirm with the 
compliance engine system the loan details. 

[0068] The client can transmit the loan data to the com- 
pliance engine system via the XML API or via a web based 
manual interface (similar to what is described above). Upon 
receipt of this data, the compliance engine system evaluates 
it and produces a Compliance Report and loan specific 
Closing Instructions (related to compensating the third party 
loan originator). The compliance engine system delivers the 
report and instruction back to the Client using the same 
mechanism that was used to request this information (i.e. 
XML API or web page). 
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[0069] After closing, there are two things that need to be 
delivered to the compliance engine system provider (appli- 

[0070] A check to compensate applicants and the 
third party originator, and 

[0071] A copy of the entire loan file for archiving 
purposes. 

[0072] Once these two items are received by applicants, 
the compliance engine system, produces a 'Compliance 
Guarantee', which is printed out and placed into the loan file. 
[0073] An exemplary sequence of events is as follows: 

[0074] The Loan Originator consults with the bor- 
rower about the property and loan products generally 
available, 

[0075] After entering the required data, including a 
self-declared credit profile, the application is pro- 
grammatically compared to available products, typi- 
cally using a service and program of the type pro- 
vided by GHR's PremierPricer™ software, or 
client's own system. 

[0076] If a list of suitable products is returned by a 
GHR-like system, the Loan Originator assists the Borrower 
in selecting the preferred loan product, The Application is 
then re-submitted to the GHR-like product selection system 
and the credit rating of the Borrower is programmatically 
obtained, 

[0077] With the 'official 1 credit rating available, the GHR- 
like system returns a list of one or more loan products, 
[0078] If the desired loan product is on the list, then the 
application process proceeds to underwriting, 
[0079] If the desired product is not available, but there are 
other loan products, then the Loan Originator and the 
Borrower will select and apply for another suitable loan 
product, 

[0080] If no loan products are available, then the system 
returns an appropriate notification, and the loan application 
is forwarded to the lender, with the initial desired loan 
product, for human review, adjustment, and probable selec- 
tion of a suitable loan product for underwriting. 
[0081] Making either selection will notify the System of 
the Borrower's intent to proceed with the mortgage loan 
origination process and will initiate the rules evaluation 
process, coincident with underwriting of the loan, as 
described in the next paragraph. 

[0082] The System's Compliance Engine will apply a set 
of rules appropriate to each mortgage loan transaction, 
including property and borrower profile, originator's pro- 
fessional guidelines, state and federal regulations and other 
relevant rules. The final filtered task list will then apply to 
each mortgage loan transaction in an attempt to assure that 
the mortgage loan is originated in accordance with appli- 
cable federal and state laws. This will include, making sure 
that qualified Loan Originators, Independent Contractors 
and Local Loan Processors are permitted to perform services 
associated with the loan origination process and that all 
services required to be performed in order for the Loan 
Originator, Independent Contractor and/or Local Loan Pro- 



cessor to receive compensation in connection with the 
mortgage loan transaction are actually performed. 
[0083] Based on the mortgage loan origination process 
requirements defined by the Compliance Engine, the Loan 
Originator will make decisions about each of the service 
providers (e.g., inspection companies, surveyors, appraisers, 
title companies, etc.) the Loan Originator wishes to have 
involved in the mortgage loan transaction. Any qualified 
service provider will be able to be selected by the Loan 
Originator and entered into the System at this point. Some 
nationwide service providers may, in the future, have a direct 
online ordering system available inside the System. Others 
may still require the typing in of the name and contact 
information. Applicants expect that it will be most common 
for Borrowers to select local service providers with whom 
they are familiar. 

[0084] After the Borrower selects the service providers, 
the Loan Processor will confirm to the system which ser- 
vices have been provided by the Loan Originator. As 
described in more detail below, the services actually per- 
formed by the Loan Originator, Independent Contractor 
and/or Ixical Ix>an Processors will serve as the basis for the 
fees earned as fair market compensation for performing 
settlement services in connection with the mortgage loan 
origination process under the Program. 
[0085] After each of the above steps are completed, the 
System will automatically create a workflow process based 
on the applicable rules and appropriate tasks will be even- 
tually assigned to each of the service providers for the 
mortgage loan transaction. In a preferred embodiment, the 
mortgage loan data and applicable tasks will be passed to a 
workflow generation system, either implemented as an inte- 
gral part of the system of the invention, or as a service 
provided by a remote application service provider (ASP), 
which will generate an automated workflow process which 
can notify each service provider of his task(s) and allowing 
each service provider to interact in completing needed tasks. 
All task assignments will be distributed by the System and 
tracked. At this point, many people will be working on the 
loan simultaneously though the System. For example, the 
Loan Originator may be obtaining financial information 
from the Borrower, the Independent Contractor may be 
ordering an appraisal, the Ixical Txian Processor may be 
verifying Borrower information, and various service provid- 
ers may be performing services and adding information to 
the mortgage loan file through the System. Hard copy data 
will be input by either Applicant's staff, an Independent 
Contractor (to the extent permitted under state law) or the 
Local Loan Processor, and added to the physical mortgage 
loan file. Work notices and status communications may be 
generated automatically by the System to keep the process 
moving and to ensure that all appropriate parties perform 
their assigned tasks in the proper order to meet all rules 
requirements applicable to the mortgage loan transaction. 
[0086] c. Products Available 

[0087] Borrowers may obtain a loan using the facilities of 
the lender organization, in which mode the system of the 
invention merely determines which tasks are required and 
tracks the completion of the required tasks. By obtaining a 
loan through the Program, Borrowers will be given access to 
a wide variety of first lien, fixed and variable rate, closed- 
end mortgage products (both purchase money and refinanc- 
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ings) at competitive rates and pricing, and in a timely and 
efficient manner. For example, as noted above, Applicants 
will make available to the Borrower, loan products and 
interest rates that are available from its participating lenders. 
Applicant's System and Program also will make available 
and support secondary lien, fixed and variable rate, closed- 
end loan products and interest rales available from its 
participating lenders. In the future, Applicants may give 
Borrowers access to first and second lien, fixed and variable 
rate, open-end mortgage products through the Program. 
Applicant's Program and System will not make available or 
support mortgage loans that constitute "Iligh Cost" or 
Section 32 mortgage loans, which are covered bv Section 32 
of Regulation Z, 12 C.F.R § 226.3 
[0088] d. Funding Source 

[0089] In a preferred embodiment, Applicants will not 
fund any mortgage loans, and no mortgage loans will be 
closed in Applicant's name. Applicants will be acting exclu- 
sively in the capacity as mortgage broker. All mortgage 
loans will be funded by, and closed in the name of, a 
participating lender. In an alternative embodiment, Appli- 
cants could fund certain mortgage loans and close loans in 
their name in those jurisdictions where qualified to do so. 
[0090] e. Disclosures and Form Documents 
[0091] In a preferred embodiment, the System will pro- 
duce applicable Borrower disclosures (on a state specific 
basis) required under applicable law to be provided to the 
Borrower in connection with the mortgage loan origination 
process under the Program. The Loan Originator will be 
required to provide the disclosures to Borrowers at the 
appropriate times. Moreover, the Loan Originators will be 
required to provide the Borrower with a disclosure that 
informs the Borrower that the Loan Originator will receive 
compensation for services actually performed by the Loan 
Originator in connection with the mortgage loan transaction. 
This disclosure also will inform the Borrower that the Loan 
Originator is an exclusive part-time W-2 employee of Appli- 
cants, and that the Borrower is free to use another mortgage 
broker or lender other than Applicants. 
[0092] The System also will allow a lender to elect to use 
a standard set of mortgage loan documents, which can be 
printed off of the System, in connection with a mortgage 
loan originated through Applicant's Program, or the Lender 
may use its own forms. The forms available off of the 
System will be provided to Applicants by a third-party 
document vendor. 

[0093] f. Mortgage Loan Fees 

[0094] Fees will generally include, among other permis- 
sible fees: (1) origination fee payable to the lender and 
passed through to the Loan Originator based on services 
performed; (2) underwriting fee payable to the lender and 
passed through to Local Loan Processor; (3) impound 
waiver fee payable to the lender and passed through to 
secondary market investor (only on loans without escrow 
accounts); (4) processing fee payable to the lender and 
passed through to Local Loan Processor; (5) document 
preparation fee payable to the lender and passed through to 
third-party vendor; (6) tax related service fee payable to the 
lender and passed through to third-party vendor; and (7) 
attorney fee payable to lender and passed through to closing 
attorney. Applicants will charge a lender a membership fee 



to participate in Applicant's Program and a flat fee for each 
Completion Certificate issued to the lender. 
[0095] g. Loan Originators 

[0096] In a preferred embodiment, mortgage loans will he 
originated through the System and Program by licensed real 
estate sales professionals, such as real estate agents/sales- 
persons and, in limited cases, real estate brokers. The 
individual real estate agents and individual real estate bro- 
kers (i.e., brokers that are not corporations or similar busi- 
ness entities) will enter into an employment agreement with 
Applicants, and become part-time W-2 employees of Appli- 
cants. The employment agreements will expressly require 
the Loan Originator to originate mortgage loans exclusively 
for Applicants, and prohibit the Loan Originators from 
receiving compensation for performing loan origination 
services for another mortgage lender or mortgage broker. 
[0097] In the future, other non-traditional originators, such 
as investment advisors, financial advisors, accountants and 
other professionals may be added to the Program as Loan 
Originators, in each case to the extent permitted by appli- 
cable law. Loan Originators may also have an affiliation with 
a mortgage lender, which defines the selection of loan 
products the Loan Originator may offer. 
[0098] i. Local Loan Processors 

[0099] In a preferred embodiment, wherein the loan is 
being processed through the system of the invention, loan 
processing functions which would trigger mortgage broker 
or similar licensing requirements under applicable state law 
will be delegated to properly licensed Local Loan Processors 
who will receive compensation intended to be fair compen- 
sation for services actually rendered by them. The Local 
Loan Processors will be either mortgage brokers and mort- 
gage bankers. 

[0100] j. Sendees Performed 

[0101] As noted above, in a preferred embodiment, a Loan 
Originator will initiate the mortgage loan process with a 
borrower using Applicant's System, I "he services that a Loan 
Originator will have to perform, in all cases, in order to be 
fully compensated include the following: (1) obtaining the 
applicant's signature on disclosures, (2) obtaining the appli- 
cant's signature on the credit authorization, (3) prc-qualify- 
ing applicants, (4) assisting applicants in selecting loan 
products, (5) taking the loan application or obtaining loan 
application information, (6) reviewing the credit decision 
with the applicant, (7) explaining the good faith estimate and 
other disclosures to the applicant, (8) collecting documen- 
tation from the applicant that is needed in connection with 
processing and underwriting the loans, (9) updating the 
applicant and responding to applicant inquiries, (10) locking 
the interest rale, and (11) scheduling and attending the 
closing. 

[0102] If a Ixian Originator docs not perform all required 
services, the services will be performed by Applicant's staff, 
Lender's staff, an Independent Contractor (to the extent 
permitted under applicable state law) or by a Local Loan 
Processor, and the compensation received by the Loan 
Originator will be reduced accordingly. 

[0103] By way of additional background, the basic of the 
rules and regulations which form the heart of the present 
invention are now described in more detail. 
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[0104] RESPA Compliance 

[0105] The following is a brief summary of RESPA and its 
implementing regulation, Regulation X, and their require- 
ments. It is not intended to be comprehensive. For example, 
RESPA and Regulation X may not apply in all situations, 
and their application is not discussed below. Users should 
consult RESPA Regulation X and independent legal counsel 
for complete explanation of RESPA Regulation X and their 
requirements. 

[0106] The Real Estate Settlement Procedures Act 
("RESPA") is a federal statute that was enacted by Congress 
in 1974. A federal regulation implementing RESPA ("Regu- 
lation X") also has been promulgated by the United States 
Department of Housing and Urban Development ("HUD"). 
HUD is the federal agency charged with administering and 
enforcing RESPA, Regulation X and their requirements. 
[0107] RESPA was enacted to provide Borrowers with 
greater and more timely information on the nature and costs 
of the home buyiug/settlement process, and to protect Bor- 
rowers from unnecessarily high settlement charges caused 
by certain practices believed to be abusive. Among other 
requirements, RESPA and Regulation X prohibit the pay- 
ment or receipt of "any fee, kickback or thing of value" (i.e., 
a referral fee) in exchange for the referral of settlement 
service business. Settlement service business includes, 
among other services, loan origination services such as 
taking applications, obtaining income verifications and com- 
municating with a borrower or lender. 
[0108] RESPA and Regulation X permit a lender to make 
reasonable payments to its agents and contractors for ser- 
vices actually performed in the origination, processing or 
funding of a loan. Based on interpretations of this provision 
in RESPA and Regulation X, real estate sales professionals 
and others may, in certain circumstances, provide loan 
origination services and receive fair market compensation 
for the services they actually perform. 

[0109] The preferred embodiment of the invention in 
Applicant's program and system are designed around this 
provision. Applicant's loan originators arc required to per- 
form certain settlement services in connection with loans 
originated by Applicants, and the compensation received by 
these loan originators and regional loan processors is 
intended to be fair market compensation for the services 
they actually perform. 

[0110] Other Federal and State Compliance 

[0111] The following is a brief summary of other federal 
and state statutes, regulations and laws that impact Appli- 
cant's system and program, and a user's performance of 
services under this system and program. It is not intended to 
be comprehensive. Users should consult the statutes, regu- 
lations and laws, and independent legal counsel, for a 
complete explanation of other applicable federal and state 
statutes, regulations and laws. 

[0112] Among other federal laws, the Truth in Lending 
Act ("TILA") and the Equal Credit Opportunity Act 
("ECOA") impact Applicant's program and system, and the 
user's performance of services under applicant's system and 
program. The TILA and its implementing regulation, Regu- 
lation Z, were enacted and promulgated to assure meaning- 
ful disclosure of credit terms so that the Borrower will be 



able to compare more readily the various terms available to 
the Borrower. Under the TILA, certain disclosures are 
required to be made to the Borrower prior to the consum- 
mation of a mortgage loan transaction. 

[0113] The ECOA, and its implementing regulation, 
Regulation B, were enacted and promulgated to require that 
lenders engaged in the extension of credit make that credit 
equally available to all creditworthy Borrowers without 
regard to race, color, religion, national origin, sex, marital 
status, age, receipt of public assistance or the fact that the 
Borrower in good faith exercised any right under the Federal 
Consumer Credit Protection Act. In addition to the prohibi- 
tion against discrimination, the ECOA and Regulation B 
also contain, among others, requirements regarding the 
provision of appraisal reports, evaluation of applications, 
spousal signatures, and the provision of adverse action 

[0114] Regarding state laws, most jurisdictions have 
enacted licensing statutes that may require real estate sales 
professionals, builders, financial institutions/lenders and 
mortgage brokers to obtain a license and satisfy various 
other financial, educational and operational requirements. 
Most jurisdictions also have enacted laws that impose, 
among others, requirements regarding the types of fees that 
may be charged to a Borrower in connection with a mort- 
gage loan transaction and the persons entitled to receive 
such fees, as well as certain jurisdiction-specific disclosures 
that must be provided to the Borrower. 

OPERATING ENVIRONMENT 
[0115] The environment in which the present invention is 
used encompasses the use of general purpose computers as 
client or input machines for use by loan originators, lenders 
and other parties interested in the mortgage loan process. 
Such client or input machines may be coupled to the Internet 
(sometimes referred to as the "Web") through telecommu- 
nications channels which may include wireless devices and 
systems as well. 

[0116] Some of the elements of a typical Internet network 
configuration are shown in FIG. 1, wherein a number of 
client machines 105 possibly in a branch office of an Real 
Estate Service, or financial institution, lender, etc., are 
shown connected to a Gateway/hub/tunnel-server/etc. 106 
which is itself connected to the internet 107 via some 
internet service provider (ISP) connection 108. Also shown 
are other possible clients 101, 103 possibly used by other 
loan originators, or interested parties, similarly connected to 
the internet 107 via an ISP connection 104, with these units 
communicating to possibly a home office via an ISP con- 
nection 109 to a gateway/tunnel-server 110 which is con- 
nected 111 to various enterprise application servers 112, 113, 

114 which could be connected through another hub/router 

115 to various local clients 116, 117, 118. Any of these 
servers 112, 113, 114 could function as a server of the 
present invention, as more fully described below. Any user 
situated at any of these client machines would normally have 
to be an authorized user of the system as described more 
fully below. 

[0117] An embodiment of the Mortgage Loan Manage- 
ment System of the present invention can operate on a 
general purpose computer unit which typically includes 
generally the elements shown in FIG. 2. The general pur- 
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pose system 201 includes a motherboard 203 having thereon 
an input/output ("I/O") section 205, one or more central 
processing units ("CPU") 207, and a memory section 209 
which may or may not have a flash memory card 211 related 
to it. The I/O section 205 is connected to a keyboard 226, 
other similar general purpose computer units 225, 215, a 
disk storage unit 223 and a CD-ROM drive unit 217. The 
CD-ROM drive unit 217 can read a CD-ROM medium 219 
which typically contains programs 221 and other data. Logic 
circuits or other components of these programmed comput- 
ers will perform series of specifically identified operations 
dictated by computer programs as described more fully 

DETAILED DESCRIPTION OF THE 
INVENTION 

[0118] In consideration of it's major aspects, the present 
invention is a system and methodology, comprising a 'con- 
tainer' concept, wherein the mechanics of real estate trans- 
actions beginning with loan origination and proceeding 
serially and in some instances in parallel through the closing, 
funding and disbursement and reporting of funds may be 
accomplished. The system also controls the timing of Lbe 
process and the time allocated to the completion of each loan 
occurrence. When the time allocated to a process expires, the 
task is transferred as required by the rule base. The system, 
constituting the present invention, is designed to program- 
matically manage and document all attendant processes with 
compliance to applicable regulatory rule sets and require- 
ments of participating workers. In a preferred embodiment, 
data exists within the executing programs as 'objects', the 
meaning of which as commonly understood by those skilled 
in the art of 'object-oriented programming'. In a preferred 
embodiment, the software programs comprising a portion of 
the present invention are also object-oriented. An integrated 
relational database management system is utilized to main- 
tain persistent data and to permit and facilitate queries and 
reports against the persistent data. While the embodiment of 
the present invention embraces certain elements of a 'closed 
loop', or self-contained decision-making process, it's 
strength lies in the ability to orchestrate the workers or 
agents participating in the lending transaction with respect to 
responsibilities and financial compensation. 

[0119] The system of the invention encompasses a means 
whereby the object-oriented 'instances' or discrete occur- 
rences of data, may be stored and retrieved from the rela- 
tional database management system. In the preferred 
embodiment, such storage and retrieval is accompanied by 
programmatic conversion of said data instances to 'formats', 
or preferred representations upon which the required pro- 
grants) may act. Such data storage occurrences and the 
accompanying manipulations of said data follow preferred 
programmatic documentation procedures such as sequen- 
tially 'nested' descriptors. An example of a sequentially 
'nested' descriptor would be, 'borrowcr.occupation', where 
the nested descriptors are separated by a '.' or 'dot', and in 
such manner are understood to mean, 'the identified bor- 
rower's occupation'. Such 'dot' notation will hereafter be 
used to describe the higher level of programmatic function- 
ality when such explanation is necessary. Those skilled in 
the art will understand JAVA™ programming, Object ori- 
ented Programming, and the use of automated "Agents" to 
perform programmed tasks whenever activated to do so, 



HTfP, XML and other communications protocols as 
described in more detail below. 

[0120] An exemplary way to articulate the concept and 
embodiment of the present invention is the idea of a 'con- 
tainer', which brings together the loan originator, the subject 
real property attributes, and the lender, as well as means to 
validate transaction profitability and bundle said transac- 
tions for sale to lenders. Or in an alternative view, as a means 
for generating the required compliance tasks for a specific 
loan transaction, provide the tasks to a lender and monitor 
the completion of all required tasks by the lender's service 
providers. The present invention provides decision points 
wherein the loan originator makes selections from menu(s) 
generated by the compliance engine acting upon the original 
information supplied by the originator. The selection process 
introduces the refined data into an integrated 'workflow' 
process wherein rule-based engines and other workers or 
agents act toward a common goal of closing, funding, 
shipping, and collecting transaction fees on a loan. 

[0121] Referring to FIG. 3 there is illustrated, in sche- 
matic form, a preferred embodiment of the present inven- 
tion. The business model is comprised of several functional 
elements, including at the highest level, embodiments which 
effect loan origination 301, closing, processing 303, funding 
305, and shipping 307, with transfer of funds. In concert, 
these elements may be referred to as the 'pipeline' or system 
which embodies the whole of the several elements compris- 
ing the present invention. 

[0122] As indicated above, the present invention is a 
method and apparatus for automating the process of gener- 
ating a set of tasks required for controlling, and regulating 
a mortgage loan application, underwriting the loan, and 
tracking the tasks through the closing process, wherein the 
tasks comply with all known Federal, State and local 
requirements for the specific loan. Elements of an alternative 
embodiment include loan origination, authenticating the 
loan originator, underwriting the loan, closing, processing, 
funding, and shipping, with transfer of funds, within the 
regulatory legal framework of funding and reporting, 
required for these processes. In a preferred embodiment, 
which is described in detail below, some or most of these 
functions may be performed by the lender or application 
service providers (ASPs) with the system of the invention 
providing the set of required tasks generated by a Compli- 
ance Engine and simply monitoring the completion of those 

[0123] Referring now to FIGS. 4A, 4B, 4C and 4D, the 
principal elements of a preferred embodiment of the present 
invention are illustrated in more functional detail. Original 
inputs from a lender/loan originator come into the system 
401 through the 'Loan Origination Gateway' (451 in FIG. 
4C) or portal, which serves as an 'entry point' or gateway to 
the 'pipeline' or system for loan originator data and bor- 
rower data. The loan originator data 403 is used as input data 
to an authentication module (453 in FIG. 4C) to verify the 
lender/loan originator's ID and password. Those skilled in 
these arts will recognize that this authentication process for 
the client/user may include digital signature authentication 
as well as other types of cryptographic verification and 
authentication of users. If the lender/loan originator's ID and 
or password do not authenticate, a message is sent back to 
the originator indicating that fact and the system exits. If the 
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loan originator is found to be qualified, the loan originator 
data and borrower data are passed to the Compliance Engine 
405 (476 in FIG. 4D) for later use. The borrower-supplied 
credit data is then passed to a Loan Origination & Program 
Matching module 407 (456 in FIG. 4C). The Iran Origi- 
nation & Program Matching module returns a list of loan 
products for which the borrower is qualified 409. In a 
preferred embodiment, this function is provided by a Pre- 
mierPricer™ program supplied by GHR Systems™ Inc. The 
PremierPricer™ Component is described in more detail at 
the GHR Systems web site, which can be found at www.gh- 
rsystems.com, which description is hereby incorporated 
fully herein by reference. Additional detail on the interface 
to this PremierPricer™ Component is provided below. In an 
alternative embodiment, the Loan Origination & Program 
Matching module is one which is supplied by applicants as 
an integral part of the pipeline system, wherein up-to-the- 
minute product and pricing information is provided when 
the module is supplied with basic transaction parameters 
(i.e., LTV, loan amount, property location, property type, 
etc.). 

[0124] Continuing with reference to FIG. 4A, borrower 
then selects a loan from the list of loan products for which 
the borrower is qualified and submits a loan application 411. 
In a preferred embodiment, the system, recognizing the loan 
application selection, submits a credit report request to a 
credit bureau 413 and passes this data to the GHR Systems 
PremierPricer™ Component 413. A list of loan products for 
which the borrower is qualified are returned to the lender & 
borrower 415. If the borrower is not qualified for any loans, 
419 the loan request is referred to a loan officer and the 
system exits 429. If the borrower is qualified, he selects one 
of the listed loans (his original selection may or may not be 
on this list) 421, 423. Referring now to FIG. 4B the lender 
uses this data to process the loan and inputs loan approval 
data to the system 431. 

[0125] The loan data is passed to the Compliance Engine 
431 (477 in FIG. 4D). As part of this set of input data the 
user/lender selects optional tasks for this loan and inputs his 
selections along with data indicative of his fee arrangement 
with the borrower 432. Referring now to FIG. 4D, this data 
is passed by the system to the Compliance Engine 479 and 
the Compliance Engine uses these data (the loan data 477 
and the user task selections 479) to generate a required set 
of tasks for this specific loan (433 in FIG. 4B). This required 
set of tasks is generated 478 by selecting the tasks from the 
task file 480 which are specifically required by the particular 
loan (i.e. loan type, location, value, etc.) and the contexts 
481 (i.e. the combinations of circumstances where the tasks 
apply). The resultant set of tasks for the specific loan 483 is 
separately recorded 482 in a file which can be modified as 
new tasks may be added or deleted, and as task completions 
are identified 485. 

[0126] In a preferred embodiment, the system can supply 
this required task list in its entirety to the lender if the lender 
wishes to manage the task completions himself through his 
own automated systems (see 441, 443 in FIG. 4B). In this 
case, the system would merely monitor task completion data 
445 (see also 485, 486, 487 and 488 in FIG. 4D) and if 
required, issue a Completion Certificate 447 when the tasks 
are completed and the loan process closed. If the user/lender 
wants Applicants to handle the loan, the Compliance Engine 
can transfer the set of tasks for this loan to an internal Loan 



Processing & Workflow engine 437. 'lluis internal Loan 
Processing & Workflow engine (Forte Conductor™, Frame- 
work Lendware™, etc) (see also 462, 463, 464, 466 and 467 
in FIG. 4C) will automatically transmit specific tasks to 
specific workers who have been previously identified as 
responsible for those kind of tasks 438, will supply task 
completion data to the Compliance Engine 440 when tasks 
are completed. The Compliance Engine will supply the 
completion data to the system so as to generate worker 
compensation and loan completion reports (see 468 in FIG. 
4C), and Completion Certificates 442. The final process 
module in the system, the Banking & Loan Management 
process (469 in FIG. 4C), adds the loan, if it was provided 
by Applicants, and its related financial parameters to the 
inventory of loans managed by applicants. In a preferred 
embodiment, this Banking & Loan Management process 
469 includes a secondary banking engine which manages the 
packaging and placing of loans with secondary financial 
institutions so as to optimize the financial returns on the 
loans handled by applicants. This process would be managed 
by Lendware™ via an on-site installation or by a Frame- 
work™ application service provider (ASP) or equivalent 
implementation. In an alternative embodiment, this second- 
ary banking engine which manages the packaging and 
placing ofloans with secondary financial institutions so as to 
optimize the financial returns on the loans handled by 
applicants would be a package developed internally by 
applicants. 

[0127] A depiction of an alternative embodiment of the 
present invention is shown in FIG. 5 which describes the 
elements shown in FIGS. 4A, 4B and 4C in a different 
depiction. Each of these features is described in more detail 
below. The 'Loan Origination Gateway '501 or portal, serves 
as an 'entry point' or gateway to the 'pipeline' or system. 
The loan originator enters data for both himself and for the 
borrower. This data is passed to the Authentication module 
503 which uses these data as inputs to the Compliance 
Engine 520. The Compliance Engine 520 uses these data 
from its associated worker's description 521 and legal 
context 523 files to determine whether the loan originator 
can originate this loan for this property. If so, the Authen- 
tication module 503"authenticates" the transaction and 
passes the information to the Loan Origination System 505 
for analysis of correspondent pricing and for underwriter 
approval. As indicated above, this function could be per- 
formed by the system or through the interface to an equiva- 
lent service such as the PremierePricer™ product supplied 
by GHR Systems™ Inc. Then the loan originator is asked to 
indicate which tasks he will do (of the optional tasks 
available) 519. These optional task and fee data along with 
the original Loan Originator data and borrower data and 
underwriter data are then passed to the Compliance Engine 
520 wherein the mandatory task identified based on the 
legal requirements for this loan originator and this location 
of the property, and the selected optional tasks are combined 
by the Compliance Engine 520 into a required set of tasks 
for this loan and passed as inputs to the Loan Fulfillment 
System 545. The Loan Fulfillment System 545 assembles 
the inputs and task requirements for input to the Mortgage 
Workflow Engine 553 which automatically manages the task 
execution by various responsible parties. In the process of 
managing the execution of the required tasks the Mortgage 
Workflow Engine 553 automatically communicates with 
parties having an interest in this loan via the Task Mainte- 
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nance & Status Reporting Gateway 550 and communicates 
with various service providers via the Transaction Service 
Provider Gateway 555. When the loan is finally closed (i.e. 
all designated tasks completed) this status is communicated 
to the Compensation & Task Performance Report system 
557 for the generation of these reports. The loan completion 
status is also communicated to the Secondary Banking & 
Loan Inventory Management system 563 which adds the 
completed loan data to the loan inventory and periodically, 
using a Secondary banking Engine 559, optimally packages 
certain loans for transfer to secondary funding sources. 

[0128] Having described a preferred embodiment and an 
alternative embodiment of the applicants invention, we now 
describe the major components in more detail. FIGS. 7-11 
indicate the basic original entry into the automated system 
and shows the kinds of data that is inputted. These data are 
then processed as follows. 

[0129] The 'Loan Application Gateway' 

[0130] Referring to FIG. 33, A loan originator, in any of 
several manifestations, may originate a mortgage loan 
request on behalf of a client, a 'borrower'. The 'Loan 
Application Gateway' provides for the Lender/Loan Origi- 
nator to enter his data and borrower data 3401 and envisions 
at a minimum, three (3) ways by which the system may be 
accessed by a loan originator; (1) via Internet website 3405 
of the assignee of the present invention, the data typically 
being in HTML format; (2) via custom-written software 
3403 which connects in a data transmission-enabled manner 
to the present invention and would typically be in XML 
format; and (3) via 'wireless' devices, including web-en- 
abled cell phones, wireless, modem-equipped hand-held or 
laptop computing devices, satellite communication devices, 
and other such wireless data and communication methods 
and devices 3407 as may come into common use, these data 
typically being in the WML or WAP formats, or other 
formats as may come into common use. The principle 
purpose of the 'Loan Application Gateway'3400, in serving 
as a portal, is to provide a way for the loan originator to 
exchange required data with to the 'Loan Application Sys- 
tem' without having to worry about what input method he is 
using and/or the related data formats and protocols. Conse- 
quently the major purpose of the input gateway is to perform 
the middleware tasks of — recognizing the input channel and 
data format and protocol used 3409 and convert the data to 
the standard Application Programming Interface (API) for- 
mat 3411 which will be used by downstream modules. This 
standard Application Programming Interface (API) format 
3411 is described in more detail below in the section 
covering the Compliance Engine. 

[0131] 'JTie input data originates from the input screens 
provided by the system. Upon making the connection to the 
Applicants system, the loan originator is presented with 
introductory screen sets ( FIGS. 7-12) and input screen sets 
(FIGS. 13-18) whereby the particular information which 
describes, to the Applicants system, the circumstances of the 
borrower, as well as the property under contemplation for 
purchase. Suitable reference and 'help' screens are made 
available to the loan originator to assist in the entry of 
required data. Notably, display information and on-screen 
prompts for data input are tailored to the nature and speed of 
the data link as well as the display limitations of the terminal 
device in use by the loan originator. 



[0132] Referring to FIGS. 7-18, such data or information 
is required for originating and underwriting a loan, and 
typically includes the following: a subscribing loan origi- 
nator's identification FIG. 7, pertinent information sufficient 
to identify the pending borrower FIG. 13, and information 
on the subject property FIG. 14. The subscribing loan 
originator's identification FIG. 7, in turn, provides the 
present invention with a profile of the originator and the 
location of the property m question thereby providing suf- 
ficient information to facilitate authentication of the origi- 
nator's qualification, according to regulations, to originate a 
loan, and otfier such information as is deemed necessary to 
logically connect the originator with agents, workers, or 
services which have been associated with the originator as 
'loan affiliates'. 

[0133] These 'affiliates' constitute a variety of resources 
which may be called upon on a loan-by-loan basis to provide 
services common in the industry, to the originator in order 
to complete the loan. 
[0134] The Authentication System 
[0135] In a preferred embodiment of the system, a Lender 
may make use of the Applicants system merely to obtain the 
set of tasks required for a specific loan, including tasks 
required by applicable federal and/or state law, and to obtain 
a Completion Certificate, or he may originate a loan through 
Applicant's network of Loan Originators also obtaining a 
Completion Certificate based upon the systems monitored 
performance of the required tasks involved. In either case 
the Loan Originator's qualifications are not verified by the 
Compliance Engine. That is, the Compliance Engine does 
not check the lenderid and property location to determine 
whether this Loan Originator is qualified to represent this 
loan applicant. 

[0136] In an alternative preferred embodiment, this 
authentication of the loan originator/lender is performed. 
This process will now be described. Upon completion of 
data entry by the loan originator, the Applicants system 
launches a validation or 'authentication' process 403 in FIG. 
4A and 503 in FIG. 5. The authentication module verifies 
the identity of the loan originator through the use of con- 
ventional means, a security 'login' typically requiring user 
names and passwords, which are programmatically verified 
as belonging to the loan originator. Various data security 
mechanisms may be incorporated in this sub-system as well, 
including the use of digital signatures as required. The 
completeness of the required input data is also verified. The 
Authentication module also authenticates the loan originator 
as being qualified to originate a loan for the property 
location specified. The module gets the loan originator and 
borrower input data 401 and calls the 'Compliance 
Engine'405, to determine whether the loan originator can 
originate this loan. If the initial queries to the legal context 
databases (these are described in more detail below with 
respect to the compliance engine description) indicate that 
the loan originator is not qualified then this "not-qualified" 
data is returned to the loan originator. If the loan originator 
is found to be qualified to originate loans in the locality a 
"yes" is returned and the authentication module may instruct 
the Compliance Engine to complete a "worker profile" for 
this loan originator, borrower and property. 
[0137] The Automatic Compliance Engine 
[0138] The Automatic Compliance Engine (the "Compli- 
ance Engine"), (458 in FIG. 4C and 520 in FIG. 5), is now 
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described in a preferred embodiment, llie Compliance 
Engine is called a number of times by several modules. 
[0139] As described above, many government, profes- 
sional, and business institutions impose requirements on 
land and mortgage lending transactions. A requirement can 
be the disclosure of specified information to the borrower, 
filling out a required form, or the gathering of specified 
information, to name a few. Applicants retains the services 
of legal professionals throughout the country who continu- 
ously gather these requirements and organize them into a 
comprehensive rule base. The purpose of the Automated 
Compliance Engine is to apply these rules in an automated 
way to identify' all requirements that apply to a specific loan 
and to track the completion of those tasks. The output of the 
engine is a task list comprised of all the tasks which the 
engine has determined need to be completed for a specific 
loan, augmented with task completion information for com- 
pleted tasks. 

[0140] In a preferred embodiment, the task list is prepared 
by selecting a subset of tasks from the list of all task 
definitions known by the Automated Compliance System. 
Tasks arc selected by evaluating expressions written in a 
dynamically interpreted programming language that test 
facts pertaining to the specific loan information. If the 
expression evaluates to true, then all tasks associated with 
that expression are added to the task list. All of the expres- 
sions in the rule base are sequentially evaluated for each loan 
instance. The Automated Compliance Engine is thus a rule 
based system, where each expression represents the 'if part 
of a rule, and the subset of tasks associated with the 
expression represents the 'then' part of a rule. 
[0141] Tor example, the following is a set of tasks for a 
given context: 



cessing and simply wants Applicants to monitor task 
completion, or it may be an automatic transmission to an 
automated workflow process engine. In a preferred embodi- 
ment, the automated workflow process engine may be 
Framework™ Inc.'s "T-endware™" program or a functional 
equivalent, such as one based on Forte Software™ Inc.'s 
Forte Conductor™ product. In this case the Workflow pro- 
cess engine presents the tasks to the persons identified as 
being responsible for doing the task. 
[0144] As each task is completed, the Compliance Engine 
receives notice of the completion event and the task list is 
updated to include the identification of the person complet- 
ing the task and the date and time of completion. The task 
list is considered completed when all required tasks have a 
completion date. Compensation may be issued to those who 
performed specified tasks with assurance that all required 
tasks have been completed and that the compensation is 
within the bounds of the laws and policies of the participat- 
ing institutions. 

[0145] Data Representation 

[0146] In the preferred embodiment, all Compliance 
Engine inputs and outputs are in represented externally in 
Extended Markup Language format (XML) which is 
described in the document found at www.w3.org/rR/1998/ 
REC-xml-19980210 which is incorporated fully herein by 
reference. XML provides an extensible hierarchical data 
structure where each element of information is labeled with 
a tag and optionally contains a value and any number of 
child elements. Internally, the same information is repre- 
sented and manipulated in a standard tree format using the 
Document Object Model tree (DOM) which is described in 
the document at www.w3.org/TR/REC-DOM-LeveI-l/ 
level-one-core.html#ID-1590626202 and which is incorpo- 



■dd>12</id> 

<tf>valCloaa.property.addres5.state')=TXVif> 

<taskNamc>TX Mortgage Broker/Loan Officer Disclosure</taskName> 
<taskNamc>Pioperty Disclosure-Seller io Buyer</taskName> 
<taskName>nWtaskName> 
<taskName>URLA</taskName> 

<taskNamc>Right to Receive Appraisal Disclosurc</taskNamc> 
<taskNamo>TX Residential Construction Contract Disclosurc</taskNamc> 




[0142] Once required tasks are identified, the engine 
applies lender task profiles in order to override task descrip- 
tion, the URL to print a form, and other task information 
provided in the standard task definitions with more specific 
values from the Lender Task Profiles. This allows a high 
degree of flexibility in customizing the engine for specific 
lender requirements, including changing the wording of the 
description of the task or changing the form that must be 
filled out. 

[0143] Once the task list has been initially prepared, it is 
presented to those persons responsible for completing the 
tasks. This may be as a simple task fist transmission to a 
lender who is doing his own loan origination and/or pro- 



rated fully herein by reference. Conversion between internal 
and external representation is provided by output methods of 
the DOM tree implementation and input methods of the Java 
API for XML Parsing (JAXP) which is described in the 
document at the URL java.sun.com/xml/docs/api/ which is 
incorporated fully herein by reference. 

[0147] For convenience in referring to DOM tree ele- 
ments, but not of necessity, the tree implementation is 
extended to provide easier tree traversal using a simple 
"get(String path)" method that takes a path argument such as 
'lask.name'. The tags between the dots '.'are parsed out of 
this path and used to search for corresponding elements in 
the tree. In this example, the get method searches for the 
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first-occurring element of the tree with tag "task". Once 
found, the get method then searches for the 'name' tag 
among the child elements of the 'task' element, and so on for 
all the tags listed in the path. Further descriptions herein will 
use this path notation to refer to specific data elements in the 
data model trees defined below. 

[0148] Alternative ways to represent and access the infor- 
mation could include files, objects, database records, arrays, 
structs, TCP/IP socket streams, 'if-then-else' statements in a 
programming language, or other ordinary means for repre- 
senting structured information. 
[0149] Data Mode 

[0150] In recognition of the need to automate as many of 
these activities as possible, to the mutual advantage of the 
real estate and mortgage loan community, the Mortgage 
Bankers Association of America (MBAA) recently origi- 
nated an effort to develop data structure standards to provide 
standardization of common business transactions in the 
mortgage industry. ihis effort is coordinated by a workgroup 
of mortgage industry representatives and is called the Mort- 
gage Industry Standards Maintenance Organization 
(MISMO). Initial deliverables of MISMO include 1) an 
XML Transaction Architecture to encompass data exchanges 
from loan origination, the secondary market and servicing; 
2) a data dictionary to provide business definitions and 
corresponding tag names of each of the data elements 
included in the architecture; and 3) a data model to provide 
relationships between the elements in the business data. The 
current versions of these deliverables are contained at www- 
.mismo.org and are fully incorporated herein by reference. 
[0151] 'ITiis description refers to the detailed data model in 
the MISMO web site mentioned above (www.mismo.org) . 
The Data Model is described therein as follows: 

[0152] "The Data Model is a tool used to understand 
the relationships between the data elements in the 
data dictionary. It is a reference to aid in building the 
XML DTD's. This is not the XML implementation 
of the MISMO Standard.." 



[0153] 


MISMO Data Model Documentation 


[0154] 


Address 


[0155] 


Address Definitions 


[0156] 


Agreement 


[0157] 


Agreement Definitions 


[0158] 


Entities Attributes 


[0159] 


Entity Listing 


[0160] 


MBA Data Model 


[0161] 


Credit Report 


[0162] 


Party 


[0163] 


Party Credit Definitions 


[0164] 


Party Declarations Definitions 


[0165] 


Party Finance 



[0166] Party Finance Item Definitions 

[0167] Party Person Definitions 

[0168] Product 

[0169] Product Definitions 

[0170] Property 

[0171] Property Definitions 

[0172] MBADataModel vl.ERl 

[0173] The Compliance Engine XML/HTTP Transaction 
API described below includes Example values for clarifica- 

[0174] The core knowledge of compliance requirements is 
represented in the 'rules' structure, consisting of 'rules.con- 
lexts' and 'rules.operations'. Each 'rules.conlexls.conlext' 
represents an if/then rule, where the 'context.if part 
describes a specified loan situation (context), and the 'con- 
text.then' part is a list of 'taskname' references to the tasks 
that are required in that context. Each 'contextif ' definition 
is expressed in a programming language statement that 
examines the facts of a specific loan and evaluates to true or 
false, as described in the algorithm description below. 

[0175] Each 'rules.operations.task' defines detailed infor- 
mation about a specific task, independent of the contexts in 
which it may be required. This information includes a 
description of the task, a URL link to any forms that may be 
required for the task, a time period within which the task is 
expected to be completed, and potentially other information 
pertinent to a task. References from the context structure in 
each 'rules, cantexts.context.then.taskname' are matched 
with the corresponding name in 'rules.operation- 
s.task.name'. In this manner, a detailed task definition is 
associated with one or more specific contexts, by task name 
reference. 

[0176] This separation between tasks and contexts is a 
convenience that allows a task to be defined in a single place 
yet be associated with multiple contexts. Alternatively, the 
'rules.operations' list could be eliminated by replacing every 
'niles.contexts.context.then.taskname' with an equivalent 
'task' structure as presently defined in 'rules.operation- 
s.task', although many of the tasks would need to be defined 
and maintained redundantly in this mode. 

[0177] Elements of a 'rules.operations.task' definition 
may be overridden by a corresponding element in an 'over- 
ride.tasks.task' definition whose 'rules.operation- 
s.task.namc' matches the 'ovcrridc.tasks.task.namo'. This 
allows customization by supplying customer-specific infor- 
mation in the task definition, such as a customer-specific 
form, description in more familiar language, or any other 
task definition element. Any number of 'override' structures 
may be applied in sequence, each overriding the result from 
the previous 'override' application. This allows overrides 
from customers, and their brokers, agents, and other affili- 
ates to be applied in any desired priority ordering that 
ultimately determines which override changes will be final. 
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The method of applying the override information is 
described in the algorithm below. 

[0178] The 'loan' structure contains all the information 
pertaining to a specific loan application. The loan applica- 
tion contains information about the borrower, the property to 
be mortgaged, its location, the loan amount, and the type of 
loan applied for. This is the information that is evaluated by 
the 'rules.contexts.context.if' expression to determine 
whether the conditions specified in the context definitions 
are true in the case of a specific loan. 
[0179] Compliance Engine XML/HTTP Transaction API 
[0180] The Compliance Engine Application Program 
Interface (API) defines structures for communication 
between the Automated Compliance Engine and the external 
environment. The request is initiated by an external agent 
with accompanying request parameters described below, and 
the response is a complete Task Status Report consisting of 
the 'tasks' list output of the engine plus the completion 
information of completed tasks. Each output 'tasks.task' 
defines a task that the engine has determined is required in 
the case of the specified loan. The list will typically be a 
subset of all defined tasks. Each task includes the detailed 
task definition information from 'rules.operations.lask', 
with some elements possibly overridden by corresponding 
task override information from 'override.tasks.task'. 
[0181] Data is exchanged via pre-authenticated HTTP in 
XML format (DTD available). It is presented in indented 
format for readability. All XML elements are required. 
[0182] The lender must provide, for each loan product, a 
description containing the product attributes that are 
required for compliance analysis, such as whether ARM, 
fixed, balloon, index, etc. Each loan application is linked to 
this information via the loanproductld compliance param- 
eter, described below, lhis must be updated whenever the 
product attributes change. 

[0183] The MISMO standard mentioned above contains 
most of the information required by the Compliance Engine 
to perform its work, but not all. The key missing pieces are 
the type of loan product the borrower is applying for, and the 
lender and agent identification. 



[0184] Loan products differ from each other in terms of 
whether they are adjustable rate (ARM) or fixed, whether the 
rate is tied to T-bills or some other index, whether there is 
a Balloon payment, whether the property will be owner 
occupied or rented out, whether there is cash out or not, etc. 
[0185] The loan product information is complex, and there 
are several compliance rules that arise out of different 
characteristics of the lender's loan product. In a preferred 
embodiment, rather than try to identify all facets of the loan 
product in a structured way and apply rules each time those 
facets are examined, instead, the loan product information is 
analyzed by hand, one time, up front, and a decision is made 
as to what compliance tasks are required for that type of 
loan. Then when it's time to generate a task Est, there is a 
single rule that indicates if you have loan product type XYZ 
then you must do tasks 1, 2, and 3. The main piece of 
information that is not provided by MISMO is the loan 
product ID, which is the id given the loan product by a 

[0186] Besides the loan product ID, the compliance API 
also requires the lender id, which is used in conjunction with 
the loan product id to fully identify the loan product, and it 
also tells us where the loan originator's pay will come from, 
which lender profile to apply, the lender to send notifications 
to, etc. The API also requires the loan originator agent id, 
which identifies who the loan originator is so he/she can be 
paid appropriately when that time comes. The loan origina- 
tor id is assigned by Applicants. 

[0187] The lender may also provide a task list profile that 

defines override values for task.description and task.fonn for 

any task. These values override the Applicants default values 

for these fields, if present. This allows lenders to describe 

tasks in their preferred terminology and to use their own 

forms, subject to compliance requirements. 

[0188] These data provided via the Loan Application 

Gateway 3400 (described above) include the following 

exemplary type data: 

[0189] New Task List Transaction 

[0190] This transaction creates a new loan compliance 

record in the Applicants compliance database, and creates 

the task list. 

[0191] Input: 



mplianceRequest 

requesrType newTasklist //same as HTTP Request-line URI resource 
lender (loan) 

Icndcrld //oncpipclinc assigned 

Icndcrlxianld //lender assigned 

agenlld //loan originator, onepipeline-assigned agenlld 

"l //loan compliance parameters. 

loanOriginationFee //$. Requires review if over 1% of loanAmount. 

loanProductld //must match id in lender-provided product 
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[0192] Output: Task Status Report (see below) 
[0193] Update Transaction 

[0194] This transaction updates the loan compliance 
record when one or more tasks are completed, or when loan 
compliance parameters are changed. If loan compliance 
parameters are changed, a new task list is generated, and the 
old one is moved to the taskListArchive section. Task 
completion information is retained in both the current task 
list and in the archived task lists. 
[0195] Input: 



[0196] Output: Task Status Report (see below) 
[0197] Task Status Report Transaction 
[0198] Output: 

[0199] Format and structure is the same for all transaction 
types. When changed loan compliance parameters require 
regenerating the task list, old task lists are preserved in the 
taskListArchive section. Completion information is present 
only for completed tasks, in both tasks and taskListArchive 
sections. 



//matches taskld from [ask in task list 

//onepipeline agent id 

//date and time in SQL format 



MnOrigirraiionFee //$. Requires review iT over 1% of 

loanProductld //must match id in lender-provided product 

ropcrtylypc //single, multiple, occupied, etc., from list 

nancingOptions //cash out, refinance, purchase, etc., from list 

//2-letter postal state code; NY, CA, TX, etc. 



>mplianceResponse 

requesflype taskStatusReport 
httpStatus 



taskld 

taskName 

display-Sequence 



completedDate 



//may be overridden via lender profile 

//.PDF printable form URL. May be ovei 

//HUD step 1, 2, 3, 4, or 5 

//Present only for completed tasks 

//onepipeline agent id 

//date and time in SQL format 



taskListArchive 
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iks //same as tasks structure above, as of date 

in (loanProductData) //same as request, with replaced loanProductld 



stepCompletion (completion) 
step (stepNumber x) 

stepNumber //HUD steps J, 2, 3, 

complete //Y or N 

feePercent //percentage ti 



loanOriginationFee, $ 
/,'onepipeline agent id if agent completed 
//fee $ if agent completed, else zero 



[0200] Algorithm 

[0201] Refer to the description of XML, JAXP, and DOM 
in the data representation description above, and to the data 
model description and detail data model elements also 
described above. 

[0202] At startup, the Automated Compliance Engine 
reads the XML-formatted 'rules' from external storage into 
memory. This XML stream is parsed by the JAXP parser into 
a DOM internal tree. For each 'rules.operations.task', the 
'task.name' is used as a key in adding task detail definition 
elements to a java.util.Hashtable to enable looking up a task 
definition by 'task.name'. Similarly, an array is loaded with 
each 'task' indexed by 'task.id', to enable looking up each 
task by the unique 'task.id' integer value. A separate hash- 
table is loaded with task override information for each 
lender, again using the 'task.name' as the key. Also, a socket 
connection to a network is opened by a web server or other 
HTTP service to enable Compliance Engine users to submit 
requests to the Compliance Engine server and to return 
responses. HTTP socket connections are describer described 
in the document found at www.w3.org/ProtocoIs/rfc2616/ 
rfc2616.html and which is incorporated fully herein by 
reference. 

[0203] Once initialized, the Compliance Engine server 
operates in a stateless request-response fashion, similar to a 
web server, following the HTTP protocol. Alternative pro- 
tocols could be used. The request and response are both 
formatted externally in XMI. format, and internally in DOM 
trees, as described in the data representation description 

[0204] The Compliance Engine API provides for three 
different request types: New Task List, Task Completion, 
and Task Status Report. These are described below. The 
response in all cases is a Task Status Report containing a 
'tasks.task' list. The remainder of this algorithm section 
describes how the task list is created or updated in response 
to these requests. 

[0205] The Compliance Engine also incorporates an 
'event generation mechanism', the purpose of which is to 



trigger actions upon the occurrence of specified events. 
These events may include a 'pushed' report where a task list 
is periodically updated according to specified parameters 
and delivered. 
[0206] New Task List 

[0207] The New Task List request consists of a 'loan' 
structure that contains information about a specific loan 
sufficient to determine which compliance tasks are required. 
[0208] The 'tasks.task' list is prepared as follows. Each 
'mles.contexts.context.if expression is evaluated, one at a 
time, in a loop from first to last. The 'if expression is written 
in the JPython programming language, which is an inter- 
pretive scripting language thai can evaluate string expres- 
sions at runtime. The Python Programming Language is 
described in the book "Internet Programming with Python" 
by Aaron Waters, Guido van Rossum and James C. Ahl- 
strum, M & T Books (Div. of Henry Holt & Co.) 1996, 
which is incorporated herein by reference. Other languages 
could be used. The expressions typically reference a specific 
element in the 'loan' structure to see if the element contains 
a specific value. 

[0209] For example, to determine if the loan property is in 
the state of Utah, the expression could be "val('loan.prop- 
erty.address.state')=UT'". The "val() method takes a string 
describing a path into a DOM tree, and returns the first value 
of the first DOM node found on that path. If the actual value 
of the 'loan.property.address.state' node of a specific loan 
was 'UT', the expression evaluates to true, otherwise false. 
When such an 'if expression evaluates to true, all of the 
associated 'rules.contexts.context.then.taskname' references 
are followed by using the 'taskname' value as a key to look 
up the referenced task detail definition through a java.util- 
.Hashtable populated at startup. 

[0210] After finding the task detail in the hashtable, the 
'rules.operations. task.name' task detail definition structure 
could be copied directly to an output task list; however, for 
convenience in the preferred embodiment, the integer value 
of the included 'rules.operations.task.id' element is used to 
set a corresponding bit in ajava.util.BitSet. This 'id' integer 
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value is unique for each task in the 'rules' set. After all rules 
have been evaluated and all applicable bits are set, the 
resultant BitSet contains a true bit for every task with a true 
'if expression. The BitSet thus represents the subset of all 
tasks which the Compliance Engine has determined to be 
required in the case of the specified loan. The purpose of this 
BitSet representation is to allow, in the future, rapid and 
simple boolean operations (and, or, or not operations on the 
BitSet) to combine task lists from different rule sets to 
improve flexibility and/or increase performance. One way to 
increase performance, for example, is to create a BitSet at 
startup time from a rule set that contains contexts that are 
always true for every loan. This initially created BitSet can 
be combined with the dynamically created BitSet using a 
bitwise 'and' operation in a manner that avoids unnecessary 
re-evaluation of some rules. 

[0211] Once a final BitSet is constructed, the program 
loops through each bit in the BitSet, and where a true bit is 
found in a particular bit position, the bit position is used as 
the index to retrieve the corresponding 'task' definition 



structure from the array that was indexed at startup time 
using the matching 'task.id' integer value. This 'task' detail 
definition structure is then copied and the copy appended to 
the DOM output tree containing the output task list. 
[0212] After constructing the list of task detail definitions 
for all required tasks, the task override information is 
applied. This is accomplished by iterating through each task 
on the output task list, and looking up the task override 
information for the lender specified in the request. If a task 
override structure is present in the table, then the program 
loops through each element in the override structure task 
definition and replaces the corresponding element in the 
output task definition. For example, if the override task 
structure includes a lender-provided task description, then 
the value of that description is copied over the top of the 
more generic description from the original rules structure. 
[0213] Exemplary Task List 

[0214] An exemplary task list generated by the Compli- 
ance Engine in a preferred embodiment is as follows: 



<name>all loan: 
<if>true</if> 



<tasiName 
<taskName>Transfer of Servic 
<taskName>ELN</taskName> 
<lasliName>ECOA</lasiName 



<id>57</id> 

<namc>Wyoming</Bamc> 
<if>statc ('WY')</if> 

<taskNamc>TEL</'tasiName> 
<taskName>URLA</taslcName> 

<taskName>Riglit to Receive Appraisal Disclosure</taskNam 
<taskNamc>Financc/Lock-in Disdosurc</taskNamc> 
</then> 



<if>valOloan.property.address.sl 

<taskName>TX Mortgage Bit 
<taskName>Property UUclosi 
<taskName>TIL</taskName> 
<taskNamc>URLA</tasl£Nam 
<tasl[Name>Right to Receive Appraisal Disc; 
<taskNanie>TX Residential Construction Cm 
Disclosure</laskName» 
</then> 



<if>((val('loan.property.address.state") == 'TX') & 
(ival('loan.loanAmount') > 50000))</if> 

-in Oisclosure</taskName> 
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<id>56</id> 

<nome>TX Commitment/Lock-in Disclosure</name> 
<description>The borrower must receive a Commitment/Lock-in 

<Eorm>http://forms.onePi 
in_Disdosure.pdf </form> 



<description>The borrowers) must sign and return the 
completed Uniform Residential Loan Application. <,'deseription> 
<rorm>hltp:/.'forms.onePipeline.mm/FNMA_n003.pdr<,'rorm3 



<reePercent>10</feePer(;enl> 
cnametoFF.</name> 

<description>The borrower must receive the Good Faith 
nstimate.</description> 

<form>http://fornis.onePipeIme.convGood_Faitli_Ei>timate.pdEc/foim 



<namc>Transfcr of Servicing Disclosurc</namc> 
<description>The borrower must complete, sign, and return 

closing. <.'dcscription> 

<form>http^/forms.oneFipeiine.com/Servieing_Disdosure_552R.pdf</ 

<role>originator</role> 
<feePer " " 



<description>The borrower must receive the Fair Lending 

tm>http://forms.onePipelme.com/Fair_Lending_Notice.pdf<,'forn 
<feePercent>5 </feePercent> 



<id>7</id> 

<name>ECOA</name> 
<description>The borrow 
Opportunity Act dil " 



Disdosure.</de.scriplion> 
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<origi_torDays>30< 



<description>The borrower must receive the Finance/Lock-in 
n>http://fonns.oriePipelke.cor£VFiiiance_l^ct_iii_Disolosur 



<id>55</id> 

<I»me>TX Mortgage Broker/Loan Officer Disclosure. 

<description>The borrower must receive a Mortgage 
Broker/Loan Officer Disclose re. </descriplion> 
<fomi>hllj 1 ://rnrins.onePipdin c .c l )rri/TX_Mortgage_Br(>kci 

_Disdosure_m4STX.ixlf<,'forni> 
<reePercenl>5</reePercenl> 



rust be completed and 
y Disclosure Seller to 



<feePercent>0 </fcePercent> 



ct Disclosure, which is to be provided by the 



<name>TX Mortgage Broker/Loan Officer Disclosure</name> 
<description>Execute ABC Company Loan Officer 
Disclosure.</description> 

<form>htt P ://forms.ABC.com/'ABC_Loan_0£acer_Disclosure.pdf</form> 
<role>Loan Originator</role> 



itial Construction Contract DisclosureWnam 
mist receive the ABC Company 
Disclosure. «/description> 




.ABC.com/ABC_Residential_Constroction_Contract_D 
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[0215] In a preferred embodiment, the original compliance 
task list for a specific loan is transmitted to the lender for 
Compliance Management or passed to an automated work- 
flow engine to initiate the dynamic workflow process. FIGS. 
37-41 contain a set of system screen shots showing an 
exemplary list of tasks required to complete a sample loan. 

[0216] An Alternative Embodiment 

[0217] In an alternative embodiment, a more general com- 
pliance system may be used, and is now described with 
reference to FIG. 5. Referring now to FIG. 5, the 'Origi- 
nator and Processor Compliance Engine'520 is comprised of 
two principle elements — the 'Worker Description' 521 and 
the 'Legal Context'523. These elements are described in 
their preferred embodiments as follows: 

[0218] The 'Worker Description '521 comprises an assem- 
blage of data sources which define the typos 525, roles 527 
and locations 529 of the workers or agents which may 
participate in the mortgage origination process. The partici- 
pation decision for a worker or agent is based upon the 
combination of features which the worker embodies and 
which make them unique when combined one with another. 
In the preferred embodiment, the worker provides a data 
prof I l r I the worker's type— that is, the type 

of service the worker may provide. The worker is typically 
representative of only one 'type' for example, either a 'Real 
estate sales professional', 'mortgage broker', 'banker', etc.. 
The specific 'role(s)' that a particular worker or agent has in 
the process is/are also defined. The 'role(s)' that a worker 
assumes arc aligned with the tasks requiring completion 
which a worker of that type can legitimately perform, 
according to the governing rule base for that specific worker 
type. These 'roles' may include such tasks as surveys, 
inspections, credit worthiness checks, employment verifica- 
tion, etc.. Orchestrating the interrelationship of these infor- 
mation sources is a 'Role Sequencing' definition or data 
table which assures a meaningful, orderly, and legal appli- 
cation of the available data. Those skilled in these arts will 
understand that various methods similar to those described 
above ill a preferred embodiment could be used for such 
sequencing activities. In an exemplary process the data 
passed from the Authentication module includes the loan 
originator used ID. This user ID is used as an argument to 
find the recorded worker type in the Worker's description 
databases where a user ID I, for example, would produce a 
Type ID1. This type ID1 would then be used to find the 
corresponding roles for this type of user and to determine the 
locations where this user id is licensed/qualified to do 
business. These data are written into a 'worker's profile' 



[0219] Referring again to FIG. 5, the 'Legal Context'523 
could comprise an assemblage of data sources which would 
contain the regulatory elements pertinent to the compliance 
and underwriting process as required by the 'Originator and 
Processor Compliance Engine'520. Included in this element 
would be tables and other data sources which are typically 
comprised of state and county regulations 531 similar to 
those described above with reference to the preferred 
embodiment, licensing regulations 533, federal regulations 
535, and professional organizational rules 539, all of which 
may govern or otherwise influence the underwriting process. 
Orchestrating the interrelationship of these information 
sources would be a 'Rule Sequencing' engine 541 which 
assures a meaningful, orderly, and legal application of the 
available data. When the 'Role Sequencing' data table and 
'Rule Sequencing'541 engines have completed the required 



processing, a profile 543 or a composite of the borrower 
requirements and property profile with applicable worker 
attributes is made available to the other modules as required 
(i.e. the Authentication module, Loan Origination module, 
workflow engine, and Task maintenance & status reporting 
gateway module). 

[0220] The 'Loan Application & Program Matching Sys- 
tem' 

[0221] Referring again to FIG. 4C, the 'Loan Origination 
& Program Matching System'456, (also see 505 in FIG. 5) 

is comprised of a multiplicity of sub-systems, to be later 
described. After this loan originator has been 'authenticated' 
as described above, this system serves as an infrastructure to 
identify various loan products or instruments suitable for 
this unique combination of borrower and property, and 
further offering a preferred recommendation of loan prod- 
ucts and participating workers or agents to effect the loan. 
The system communicates with the loan originator and 
requires him to complete the actions and provide the addi- 
tional borrower data and instructions shown in FIGS. 12-17. 
[0222] As indicated above, in the preferred embodiment of 
the invention, this Loan Application & Program Matching 
System' is preferably performed by a system such as GHR 
Systems™ making use of their PrcmicrWarc™ product. This 
GHR product is also an object oriented product, however the 
objects employed are Microsoft COM™ objects which 
require Windows NT™. The web server architecture of 
applicants system is UNIX based which necessitates using 
Java and the Common Object Request Broker (CORBA) 
system to communicate between the UNIX and COM based 
object systems. The architecture of this communications 
interface is described below with reference to FIG. 34. 
[0223] With reference to Applicants's use of this Premier- 
Ware™ product, the following description pertains. The 
input and output data elements that play a role in Applicant's 
use of the GHR Underwriting Framework known as Pre- 
mierWare are now described. Applicants implemented the 
framework within a distributed architecture encompassing 
several technologies including Java, CORBA, COM, and 
Delphi (Object Pascal). First, how the GHR components 
interact with each other arc described, followed by the 
Applicants implementation around that interaction. 
[0224] GHR Systems' PremierWare framework is a set of 
software components that adhere to the component object 
model (COM) sponsored by Microsoft. Inc. The framework 
is provided to facilitate the qualification of borrower cre- 
dentials, i.e., income, debts, etc., against mortgage loan 
programs. The desired result being to locate a loan program 
for which the borrower is qualified. The framework is 
functionally divided internally representative of three pri- 
mary operations: 

[0225] Product Filtration: Narrowing the number of 

programs available for qualification processing. 
[0226] Qualification: Extracting the programs for 

which the borrower is qualified to apply. 
[0227] Ancillary Utilities (Helping): Packaging and 

unpacking data as it moves in and out of the GHR 

API. 

[0228] Product Fileration 

[0229] If no product filtering is performed before qualifi- 
cation, then qualification processing is completed on all 
products in the GHR products database. Filter criteria can be 
set using any or all of the data elements below: 
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PropertyCounty 

PropertyZip 

LocKType 

LockDoys 

PricePreference 



ProgramlD 

POC (Product Group 

Code) 



FixedRateMo rtgages 
AdjuslableMorlgages 
BaloonMortgages 



[0230] The result of a Product Filtering operation is a set 
of loan programs that serve as the input to a Qualification 
operation. Within the framework, the Pricer object's Get- 
ProductsForQualification method is used to perform a fil- 
tering operation. Once a set of loan programs is received 
from GctProductsForQualification, then qualification can 



[0231] Qualification 

[0232] The first step in qualification is selecting a Quali- 
fication Method. There are fourteen methods in total, which 
are grouped into four Modes. The four Modes are: 

[0233] Buyer/Purchase 

[0234] Cash out Refinance 

[0235] No Cash out Refinance 

[0236] Shopper 



EstimatedTaxDollars 

EstimatedHazInsDollais 

VASlaUis 

AssodationFee 

FlCOScore 

FICORejectCnde2 
FICORejeclCixle.l 



Boolean 
Boolean 



Buyer/Purchase Mode 
BuyerAvailableCash Qualification Met 
Qualifies a borrower based on his/her cash av 



BuyerMaxLoan Qualification Method 



Buyer/Purchase Cash out Refinance No Cash out Refinance Shopper 

BuyerBaseLoan CashoutRefiMaxCashout NoCashRefilnclFee Shopper 

BuyerAvailableCash CashoutRefiSpecifyCashout NoCashRefiSpecifyLoan 

BuyerMaxLoan CashoutRefiSpecifyLoanAmt NoCashRefiSpeciryLTV 

BuyerBaseLTV CashoutRefiSpecifyLTV NoCashRefiNoCostRefi 
BuyerDesiiedPrn 



[0238] The grids below and on the following pages outline 

these modes and the various methods available in each -continue d 

Mode with each method's input parameters. There is a core Qualifies a borrower for the maximum loan amount 

set of input parameters that are Used for all methods, and All Properties are the same as the BuyerBaseLoan except 

then under each method, there are one or more variations BascLoan is removed. 

that are indicated in context. ~ ' ~~ ~ 
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Al! Properties are the same as th 



percentage of download 
BuyerBaseLoan except 



Inte 



Buyer/Purchase Mode 
BuyerDesiredPITI Qualification Method 
Qualifies a borrower based on his/her desired monthly 

All Properties are the same as the BuyerBaseLoan except 
^ BaseLoan is replaced by DesiredPITI. 



iiredPm 



Shopper Mode 
Shopper Qualification Method 
Qualifies a borrower who is shopping for a house and does not 
have a specific property. Also known as "affordability analysis " 
All Properties are the same as the BuyerBaseLo tn except 
BaseLoan is removed but MaxLTV, MaxPITI, and AvailableCash are 
added as well as two percentage fields: EslimaledTaxesPercent and 
RMimatolHa/.InsPetcent and n MaxPoinLsAsOift field. 



OHR Term 



Date Type 



EstimatedTaxesPerce 
EstimatcdIIazInsPerc 
MaxPointsAsOift 



No Cash Out Refi M 



Qualifies a borrower with a : 



FICORejectCodel 

FICORejectCode2 

FICORejectCode3 

CurrentMtgBalancel 

CurrentMtgBalance2 

CurrenlMtgBalance3 

CurrentMtgRatel 

CurrentMtgRate2 

CurrentMtgRate3 

CurrenlMtgPrni 

CurrentMtgPITO 

CurrentMtgPm3 

CtirrenlMtgRemaiaiiigT 

QrrrentMtgRemainingT 

CurrenlMtgRemainingT 

CurrentMtgEI.OC_2nd 
CurrentMtgELOC_3rd 
CurrentMtgToBePaidOf 

CurrentMtgToBePaidOf 
£2 

CurrentMtgToBePaidOf 



String 



in Buyer Mode 

Defined 

in Buyer Mode 



RequestedPoints 
RequestedCeiling 



in Buyer Mode 
in Buyer Mode 



Defined 

in Buyer Mode 

Defined 



No Cash Out Refi Mode 
NoCashRefiSpecifyLoan Qualification Met 
ifies a borrower with a specified refinance la 
roperties from NoCashReflncludeFee remain 



MonthlyDebt 
CurrentHsgExpense 

YearsExpectedinHouse 



IgnoretncomeRatios 
FrontRalioOverride 



in Buyer Mode 
in Buyer Mode 
in Buyer Mode 
in Buyer Mode 



In Buyer Mode 
Boolean Defined 

in Buyer Mode 
Boolean Defined 



No Cash Out Refi Mode 
NoCashRefiSpecifyLTV Qualification Method 
lifies a borrower with a specified percentage of ex 



No Cash Out Refi Mode 
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allows the closing 



k as the NoCashReflncludeFee 



Cash Out Refl Mode 
CashoutRefiSpecifyCashout Qualification Method 
Qualifies a borrower with an amount that will pay off the 
;ting loan balance with a specified cash out to the borrowe: 

Pi erti are th to tn CashRefl del «■ ■ 
qualificati on mcl hud plus an AvailabteCash field. 



Dale Type 



Cash Out Rcfi Mode 
CnshoutRefiSpecifyLlV Qualification Method 
Qualifies a borrower with a specified loan to value ratio, 
nple: 7U% urv for an existing loan balance of $70,U00 will rei 



[0239] Credit Profile Inputs 

[0240] Each of the qualification methods also accept two 
input arrays for specifying aspects of the borrower's credit 
profile. These elements improve the accuracy of the Quali- 
fication Results. A Credit Report is retrieved electronically 
from a certified credit-reporting agency and prepared for use 
by the GHR interfaces. The two array elements are: 

[0241] Liabilities 

[0242] Public Records 
[0243] The data elements for setting these arrays are 
provided below: 

[0244] Liabilities 
[0245] SetNumberOfRecords(Integer); 



[0246] BorrowerNumber 

[0247] LateDaysLiabilityTypeMonths- 
FromDateReported 

[0248] Public Records 

[0249] SetNumberOfRecords(Integer); 

[0250] BorrowerNumber 

[0251] MonthsRecordClosed 

[0252] MonthsRecordOpened 

[0253] RecordType 

[0254] Amount 

[0255] GHR Qualification Results 

[0256] Two sets of records are returned from each quali- 
fication request. A set of products (Loan Programs) and a 
corresponding set of closing costs. There is a one-to-many 
relationship from each Ix>an Program to the array of Closing 
Cost Records. The layout of these fields is depicted below: 



PreQualOulpul Record Qmn Programs) 

RejectionFlags Integer 
TotalLoanAmount 
BaseLoanAmount 
SalePrice 
Cl05ingCosts 

StartingPrn Integer 



Ml 

■taxes 
Hazlns 
RequiredCash 

PrnReserves 
OriginationFee 
UpfrontMI 
MIFinanced 

QualRate 



BreakEvenMonthNoRein 



US 2001/0047326 Al 



24 



Nov. 29, 2001 



PaidOutsideClosini 
VHAAllowable 
AppliesToMods 
Financed 



FromZip 
Mortgagee 



Boolean 
Boolean 
Boolean 



[0257] Applicants Implementation 

[0258] In Applicant's architecture, the GHR components 

are wrapped with a CORBA interface using Borland's 

Delphi development tool (Object Pascal). This interface 

exposes a single method 'Qualify' that accepts five input 

parameters: 

[0259] Qualification Method 

[0260] Filter Parameters 

[0261] Qualifications (Borrower Data) 

[0262] Borrower Liability Data (From Credit Report) 

[0263] Borrower Public Record Data (From Credit 
Report) 

[0264] With the exception of 'Mode', which is an integer 
value, all the other parameters are Strings. The Strings are 
formatted (delimited) with structures to be easily disas- 
sembled for use against the GHR COM interfaces. The 
format makes use of industry standards such as XML and 
XMLT Data is sent to and" from the CORBA interfaces 
utilizing HOP over TCP/IP. 

[0265] Any CORBA client can tie directly into the GIIR 
CORBA server once the input parameters are satisfied. In 



our implementation, a set of JavaBeans comprise the client 
side of our architecture. There is a JavaBean representing 
each of the Qualification Methods expressed by GHR. The 
JavaBeans expose mutater methods for setting each element 
of the input parameters for Filter Parameters, Borrower 
Liability Data, Borrower Public Record Data, and Qualifi- 
cations. The Qualification Mode is encapsulated within the 
JavaBean corresponding to the GHR qualification method. 
All of the JavaBeans expose a QualifyO method through 
inheritance that performs all of the CORBA location and 
marshalling functions necessary to interact with the GHR 
CORBA Server. The result of the QualifyO method call is a 
delimited String representing the 'PreQualOutput Records' 
and 'Closing Cost Records' described above. Navigating the 
output is facilitated by a special IqualifiedProducts JavaBean 
which receives the formatted return String, parses the 
records, and exposes methods for accessing individual ele- 
ments of semantic importance as also outlined in Qualifi- 
cation Results section above. These JavaBeans are depen- 
dent on the visibility of the GHR CORBA Server via an HOP 
channel and are not well suited for integration with the 
outside world. 

[0266] To expose the functionality of the Qualification 
features of the Applicants system to the outside world, the 
JavaBeans encapsulation of the GHR CORBA Server's API 
is further abstracted to facilitate clients via the HTTP 
protocol. A Java enabled HTTP server is positioned to 
intercept function calls via the outside world and pass them 
into the JavaBeans which in turn make their normal CORBA 
requests to the GHR CORBA Server. 
[0267] Referring now to 34, with reference to the descrip- 
tions above, this Applicants-GHR Systems communications 
interface is defined in functional overview. An HTTP server 
receives inputs from applicants' system, wherein requests 
for data are processed and an instantiation of a GHR client 
JavaBean occurs based on type of qualification desired 
3503. These GHR JavaBeans provide an API into the GHR 
CORBA Server using distributed computing data marshal- 
ling over the Internet Inter-ORB Protocol (HOP) 3505. The 
HOP request is transmitted to a GHR CORBA server 3509 
where the data from the client JavaBeans are accepted, 
unmarshalled and used to trigger the instantiation of the 
GIIR Systems COM objects. The GIIR system using its 
COM objects, processes the request and returns qualified 
loan programs (if any). These data are formatted into an 
XML data stream and sent back to the client JavaBean. 3511. 
The Applicants system code receiving the XML datastream, 
parses the datastream and creates an HTML document for 
return to the calling web browser for end-used interaction. 
[0268] In an alternative embodiment, subprograms for 
performing the functions equivalent to those of the GHR 
system would be developed internally to applicants system. 
[0269] The 'Originator Task Menu and Origination Fee 
Assessment' Function 

[0270] As indicated above, upon completion of the loan 
selection and formal loan request, the loan originator is 
given the screen shown in FIG. 28A and is asked to specify 
the loan origination fee and to choose the functions in steps 
3, 4 and 5 which the loan originator will do. The 'Originator 
Task Menu and Origination Fee Assessment' function 519 in 
FIG. 5 uses these selections as well as the other non-selected 
required tasks to construct the inputs which are passed to the 
Compliance Engine as described above. 
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[0271] The 'Loan Fulfillment Workflow Process' 

[0272] The composite of information which is passed to 
the 'Loan Fulfillment Workflow Engjne'545 in FIG. 5 as a 
new 'context' or data embodiment, and by which a new, 
discrete, mortgage process is created comprises the summa- 
tion of data or information supplied by the 'Compliance 
Engine'520, the list of tasks related to the specific loan as 
described above. In a preferred embodiment, the list of tasks 
for the specific loan arc delivered by the Compliance Engine 
to the Loan Fulfillment System (462 in FIG. 4C) which 
comprises a Loan Processing and Mortgage Workflow 
Engine such as Framework, Inc.'s Lendware™ product. In 
an alternate embodiment the 'Loan Fulfillment Workflow 
Engine'545 in FIG. 5 is contained within applicants' system 
and would be built around the Sun Microsystems™ Inc. 
Forte™ Conductor™ engine product to manage and control 
the related business processes and to provide a runtime shell 
to facilitate coordination of application services within the 
business process. The various business applications related 
to the steps to be processed in completing the mortgage loan 
closing are pre-defined to the Forte Conductor system Oust 
as they are in the Lendware product) so that when the 
'mortgage functions' and their designated 'actionees' (if 
any) are passed to the 'Loan Fulfillment Workflow Engine' 
and to its Forte Conductor engine, these 'functions' are 
executed in an integrated environment where both the func- 
tion process definition and each of the supporting applica- 
tions is pre-defined and will execute automatically. The 
supporting applications are a set of application proxies, each 
representing the business service provided by its application 
and the pre-defined actions to take are contained in an XSL 
rule base, consisting of rule documents. Specific rule docu- 
ments are assigned to proxies so they can interpret and 
transform messages The 'Loan Fulfillment Workflow 
Engine'545 and its Forte Conductor engine assures that 
processes happen in the correct sequence and in accordance 
with the (software controlled) pre-determined, program- 
matic branching conditions defined by the 'Worker Profile 
Attributes'543 business process definition. The 'Loan Ful- 
fillment Workflow Engine'545 may call upon any combina- 
tion of 'workers', heretofore described as computers, data 
tables, software, persons, organizations, companies, or other 
data sources, etc. to perform the required tasks. The 'worker' 
or 'agent' is typically manifested in one or more of the 
following ways: as an individual, an organization, one or 
more data tables, a data processing system, or the like. 

[0273] In this alternative embodiment the pre-pro- 
grammed functional steps executed by the Forte Conductor 
system are shown in FIG. 6. The types of activities repre- 
sented by the icons on FIG. 6 include the following; 



Icon Description 

Opening door Beginning of a new process, in this case a new loan 

Closing door Ending of a process 

Computer Automated activity that does not require human 

Alarm Clock Timer activity which initiates the next activity based on 
passage of time 



[0274] The process definition drawing shown in FIG. 6 
defines the process activities for the Applicants.com com- 
pliance workflow system. By performing the defined activi- 
ties under the strict control of the Conductor workflow 
engine, the engine ensures that all required tasks are com- 
pleted, and in the required sequence. The engine presents 
activities only to workers whose role designations match the 
role designations of the activity. The earlier system activities 
assigns roles in advance to workers only after verifying that 
the pre-requisite qualifications are satisfied. In this fashion, 
loan originators are assured that all applicable pre-qualifi- 
cations are satisfied and that they actually performed all the 
services for which they were compensated. When a loan 
process is initiated in the workflow system a call is made to 
the Forte Conductor software to instantiate a new loan 
workflow process for the specific loan, as indicated by the 
parameters passed in the calling sequence. 

[0275] 'litis workflow process is better understood with 
reference to FIG. 6. Referring now to FIG. 6 , the loan 
originator 601 gathers credit data, gets authorization and 
requests puU credit 603. The automated system 607 pulls 
credit 609, processes the credit report, parses FfCO, public 
records and liabilities 611, and the credit profile is saved to 
the Oracle™ data base 612. If this credit clearing process 
exceeds 15 minutes a timeout occurs 615 and a message is 
sent to the user indicating a failure in the credit processing. 
When the credit profile is completed and saved to the 
Oracle™ data base 612 and the loan originator 601 has 
completed the loan wizard and Express app via the website 
604 the system then begins the underwriting assessment 
617. If the FICO previously determined in step 611 is not 
less than 620 the process driver submits the request to 
automated underwriting 621. If it is approved 623 the system 
generates task fists and compliance documents (GFE, TIL, 
Disclosures, etc.) 625 and submits them, to the loan origi- 
nator 627, to the premium broker processor 649, to the 
premium broker account executive 651, for their individual 
completion of their respective tasks to complete the loan 
process. The loan originator 627, the premium broker pro- 
cessor 649, and the premium broker account executive 651, 
all electronically submit a task completion message to the 
system 631 and it compares the submissions against autho- 
rization criteria 633. If the criteria are met the system 
determines whether the user has requested that the loan rate 
be locked 635 and if so the loan is loeked-in with the 
investor 661 and a message is passed to the clear-to-close 
auditor 665, 659 where a determination is made as to 
whether the transaction is clear-to-close 667. If so a message 
is passed to the closer 669 to close the loan 677. A message 
is then passed to the funder/shipper 671 to fund/ship the 
loan. The funder/shipper 671 does two things: first it verifies 
the investor purchase of the loan 683 and notifies the 
controller 675 to update the general ledger that funds have 
been received 689 and tells the end transaction mechanism 
691; secondly the funder/shipper 671 tells the controller 675 
to update the General Ledger to disburse the funds 687 
which submits a requisition to payroll 685 who notifies the 
end transaction mechanism 691. 

[0276] The system has capabilities to determine that the 
required criteria have not been mel/compleled 633 and 
determine whether to resubmit the loan request to automated 
underwriting 639, 640 or to notify the underwriter 641 to 
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iterate on the credentials review process 643 and either deny 
645, 647 the loan or approve it 645, 623 and generate the 
task lists again 625. 

[0277] Thus the loan process in this alternate embodiment 
is driven through the required tasks by the Forte Conductor 
engine to assist in the complying with the various regula- 
tions and yet automate the process in a helpful and efficient 
manner. In the preferred embodiment the ASP system Lend- 
Ware or its equivalent drives the loan process and the 
individual task workers in a manner similar to that described 
above. In the preferred embodiment the task completion data 
is passed to the Compliance Engine which monitors the list 
of tasks for each loan and which can also communicate 
directly with some task workers when certain critical events 
occur or timeouts are perceived. 

[0278] The 'Task List Maintenance and Status Reporting 
Gateway" 

[0279] The 'Task List Maintenance and Status Reporting 
Gateway"550 in FIG. 5 or 463 in FIG. 4C serves as a portal 
to communicate to and from other agents and workers who 
are qualified to perform assigned taste. These taste are those 
which would be assigned by the 'Loan Fulfillment Workflow 
Engine'545 or by the ASP workflow processor Lendware 
463 to other agents or workers to complete prior to the 
closing of the loan and distribution of funds. While this 
gateway is similar to the 'loan origination gateway' it is 
significantly different in that the middleware layer must 
handle the conversion of data format and protocol of the 
Forte Conductor engine or the Lendware workflow engine to 
and from the formats and protocols of the agents/workers to 
which the workflow process is communicating. Accordingly, 
The 'Task List Maintenance and Status Reporting Gate- 
way'550 in FIG. 5 is used to transmit messages from the 
workflow engine to these other agents and to receive 
responses from authenticated agents. These agents would be 
performing tasks such as 'title search', 'survey', 'credit 
check', etc. The 'Task List Maintenance API and Status 
Reporting Gateway'550 can also use the same interface 
modes as envisioned for The 'Loan Origination Gate- 
way'505. Envisioned are at least, three (3) ways by which 
the system may access and be accessed by a loan agent/ 
worker: (1) via Internet website, (2) via custom-written 
software which connects in a data transmission-enabled 
manner to the present invention, and (3) via 'wireless' 
devices, as previously described for the 'Loan Origination 
Gateway'505. 

[0280] A loan originator or borrower may also come into 
the system via this gateway to check the status of the loan 
process, etc. As indicated below every entrant via this 
gateway must never-the-less be authenticated before entry is 
allowed. Conveyance of task lists to a loan originator and 
associated workers and reporting of borrower loan status are 
accomplished through a programmatic presentation 552 
which embodies the following: 'borrower status rcport(s)', 
'originator's task list', and 'other worker's task lists' (as 
described above) — said information exchanged through this 
'task maintenance & status reporting Gateway' (the "TMSR 
gateway"). This 'TMSR gateway', functions in a manner 
similar to that used during the loan origination process. 
Reports may be conveyed by a variety of programmatically 
controlled means, such as web pages, PDF® files, word 
processing format files, etc. The TMSR gateway receives the 



direction messages from the 'Loan Fulfillment Workflow 
Engine'553 in the standard Forte Conductor or Lendware 
API format, and using the middleware layer described 
before, converts the format and message protocol into that 
required to communicate with the desired agent/worker. 
Similarly, the TMSR gateway can receive messages from the 
various agents/workers in various formats and protocols (i.e. 
HTML, XML, WML, WAP, etc.) and converts these mes- 
sages and protocols into the standard API formats used in the 
preferred embodiment. 

[0281] Referring now to FIG. 36 the principle purpose of 
the 'TMSR Gateway'4200, in serving as a portal, is to 
provide a way for the loan originator and borrower to check 
the status of the loan process and for the 'loan process 
workflow engine' to communicate to and from the other 
agents/workers who are doing some task required by the 
process, without having to worry about what input method 
or output method is required to communicate with a given 
entity, and/or the related data formats and protocols. Con- 
sequently the major purpose of the TMSR gateway is to 
perform the middleware tasks of — recognizing the input 
channel and data format and protocol used 4209 and convert 
the data lo the standard workflow engine Application Pro- 
gramming Interface (API) format 4211 which will be used 
by the workflow engine. Similarly, on receiving a message 
to be transmitted from the workflow engine, the TMSR 
gateway middleware structure is required to determine the 
format & protocol used by the addressee and convert the 
message from the workflow engine API format into the 
format and protocol of the addressee 4215 and then transmit 
the message 4217 to the addressee 4203 or 4205 or 4207. 
The input data originates from the input screens provided by 
the system, and from the output data pre-defined in the 
various task elements in a typical loan workflow process. 
The workflow engine will typically transmit a required 
message whenever an event occurs which requires a mes- 
sage be sent or resent (because of a timeout for example). 

[0282] The TMSR gateway is required to pass the received 
data to a second authentication module 549 in FIG. 5 or 464 
in FIG. 4C. This authentication module once again verifies 
the used ID and password of the inputting user. In the 
preferred embodiment this check does not verify the legal 
qualifications of the user. In an alternative embodiment, the 
user ID is checked to determine the worker Type, and the 
roles this type worker may perform for this location of the 
properly and for his location are verified against the role he 
is attempting to play. Similarly the compliance engine 
checks to see if the various legal regulations allow this 
agent/worker to perform the role they are attempting to play. 
If so the authentication module 4212 in FIG. 36 will pass the 
data submitted to the aforementioned workflow engine 42 13 
for its processing of the incoming data in response to the task 
assigned. 

[0283] Transaction Service Provider Gateway 

[0284] Returning now to FIGS. 4C and 5, the 'Vendor 
Management API Gateway 467 in FIG. 4C or the 'Trans- 
action Service Provider Gateway'555 in FIG. 5 serves to 
manage 'tasks' assigned to external agents or workers or 
vendors with whom Applicants' have a special vendor 
relationship. That is, a vendor who supplies appraisals in a 
given locality, loan processing, credit checks, title searches, 
flood certification, mortgage insurance, etc. The 'Vendor 
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management API Gateway' or the 'Loan Fulfillment Work- 
flow Engine', (see FIG. 6 for example) in developing a task 
list for the loan originator (627 in FIG. 6), recognizes some 
tasks as falling under the responsibility of the loan originator 
as determined in the loan origination process, and some 
tasks which are to be automatically forwarded to certain 
service provider agents or vendors. The communication of 
these assignments, occurs in a different manner than those 
described above relative to the TMSR gateway. Since these 
tasks tend to be more routine and repetitively performed by 
the specific vendors, the workflow engine will send a 
message to the designated vendor and wait (i.e. maintain the 
telephonic or electronic connection) until the vendor sup- 
plies the desired response (which normally would be within 
a few minutes) or until a watchdog timer expires. If the timer 
expires the workflow engine will try the communications 
again as well as notify a system manager that the vendor has 
not responded. 

[0285] For example referring now to FIG. 36 the 'trans- 
action service provider gateway' (the "TSP gateway") 4400 
is described. The functioning of the 'Vendor Management 
API gateway' under the control of Lendware, for example, 
would function similarly. Whenever the workflow process 
for this loan 4401 recognizes an event/task which requires a 
communication to a vendor/partner (service provider), the 
workflow process constructs the message and passes it to the 
TSP gateway 4403. The TSP gateway determines the format 
and protocol required to communicate with the indicated 
service provider and translates the message from the work- 
flow process formal into the required format and protocol fur 
the service provider 4405. The TSP gateway then establishes 
a persistent communications link with the service provider 
4407 and sends the message and waits for a response 4409 
. If the service provider does not respond in a given lime a 
watchdog timer expires 4411, 4413 in which case the system 
administrator is notified 4415 and the message is resent 
4409. If the service provider responds within the allotted 
time 4423, 4425 the circuit connection is released 4427 and 
the response is translated from the format and protocol of the 
service provider into the format required by the workflow 
process 4429 and the response is passed back to the work- 
flow process 4431. 

[0286] During the course of the workflow process execu- 
tion of the various tasks as shown in FIG. 6, the workflow 
process engine records each transaction into an Oracle 
database in order lo create and maintain an audit trail of 
tasks performed for this loan, when performed, by whom, 
etc. This database is used for certain reports triggered by 
other tasks in the workflow process as well as ad-hoc reports 
of tasks completed for various compliance and maintenance 

[0287] Worker Compensation and Task Performance 
Report Module 

[0288] The 'Worker Compensation and Task Performance 
Report' Module 468 in FIG. 4C or 557 in FIG. 5, provides 
a mechanism for producing reports lo accounting lo distrib- 
ute funds to those agents/workers who have earned them in 
a particular loan transaction. These reports in a preferred 
embodiment are normally triggered by the Compliance 
Engine but may be triggered in an alternative embodiment 
by the loan workflow process for that loan at certain pre- 
defined points in the workflow. This module also provides 



the capability for generating regulatory completion reports 
and/or Completion Certificates as required for each loan. 
[0289] The 'Secondary Banking Process' Module 
[0290] The 'Secondary Banking Engine' module 469 in 
FIG, 4C or 561 in FIG. 5 serves to manage loan transactions 
as they are introduced to the secondary lending pool, and 
move them programmatically through the process of 'clos- 
ing', 'funding', and 'shipping' the loan transaction. In one 
embodiment, 469 in FIG. 4C, is managed by Lendware via 
on on-site installation or equivalently by Framework ASP. In 
an alternative embodiment, the secondary banking functions 
would be managed and processed within applicants' sys- 
tem.561 in FIG. 5. In the alternative embodiment, the 
'Secondary Banking Engine'561 would also serve as the 
mechanism whereby the transactions and finds distributions 
involving the bundling and selling of loans to the secondary 
banking institutions are verified and reported in the follow- 
ing manner: (a) 'Locked Loan reports, tracking all loans 
locked by borrowers, and reported on a regular schedule, (b) 
Commitment report, tracking all unfulfilled loan commit- 
ments, (c) Funding report, which tracks and reports initial 
funding status (d) Funded, but not Shipped report, (c) 
Shipped but not Purchased report, and (f) Purchased Loan 

[0291] In an alternative embodiment, a special task of the 
secondary banking module is to manage use of the funds in 
the warehouse credit line. The management objective is to 
optimize the financial return generated by the funds in the 
warehouse line of credit. If too much of the warehouse line 
is consumed in covering mortgage loans processed, the 
overall return on these funds is diminished. Accordingly the 
management task is to move mortgage loans from the 
warehouse line to secondary investors as quickly as pos- 
sible. This may be done by selling individual loans to 
secondary investors, or by pooling multiple loans, according 
to various credit conditions and pooling rules for sale to 
other secondary investors. 

DESCRIPTION OF THE BEST MODE 
[0292] Referring now to FIGS. 31-32 the various types of 
computer hardware and computer software used in a pre- 
ferred embodiment at the present time are depicted. In FIG. 
31 it is clear that Sun® Ultra5™ workstations 3101 and 
general purpose Personal computers (PC) 3 103 may be used 
as input devices to the system. A Sun E250™ dual processor 
server 3105 is used as a developmenl/lest system running the 
Sun® Solaris® operating environment, Oracle® 81, Forte® 
Conductor™ with a SynerJ™ server. A single processor Sun 
E250™ server 3107 is used in the Sunnyvale facility. Also 
in this facility are three Sun E4500™ dual processors 3117, 
3119 and 3121, an IBM NetFinity 7000™ quad processor 
with a Microsoft® NT™ server 3115 and a Hitachi Shared 
Disk array 3123. There are also three IBM NetFinity 5000™ 
servers 3109, 3110 and 3111 located in the Salt Lake City 

[0293] In FIG. 32 it may be seen lhat loan originators 
interface to the applicants system using a standard Internet 
browser such as Internet Explorer™3201 with the initial 
interface in applicants' system being with Lotus® 
Domino ™3203. The system Ihen performs the Pre-qualifi- 
cation and Loan application & Approval using GIIR® 
Systems PriemierWare™3209. The Sun Solaris® operating 
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environment in the system server (at 3203 in FIG. 32) 
interfaces with the GHR system 3209 and to FastDi- 
rect™3211 via HOP through a CORBAto COM bridge and 
a Delphi Automation interface to Windows NT™ . Solaris™ 
interfaces in this configuration to the Oracle 81® server via 
Forte® Conductor™3207 through Forte Enterprise Java- 
Beans, Forte Distributed JavaBeans and HOP. 
[0294] Having described the invention in terms of a pre- 
ferred embodiment, it will be recognized by those skilled in 
the art that various types of general purpose computer 
hardware may be substituted for the configuration described 
above to achieve an equivalent result. Similarly, it will be 
appreciated that arithmetic logic circuits are configured to 
perform each required means in the claims for performing 
the various features of the rules engine and flow manage- 
ment. It will be apparent to those skilled in the art that 
modifications and variations of the preferred embodiment 
are possible, such as different computer systems may be 
used, different communications media such as wireless 
communications, as well as different types of software may 
be used to perform equivalent functions, all of which fall 
within the true spirit and scope of the invention as measured 
by the following claims. 

We claim: 

1. A computer implemented method for generation of a set 
of required procedures for processing a mortgage loan using 
an Internet based system having a client loan origination 
system electronically coupled to an automatic compliance 
engine, the method comprising the acts of: 

the automatic compliance engine receiving a request to 
process a mortgage loan from the client loan origina- 
tion system; 

the automatic compliance engine generating a plurality of 
tasks, the tasks comprising actions required to process 
the mortgage loan, including tasks required by appli- 
cable federal or state law; and 

the automatic compliance engine distributing one or more 
of the tasks to the client loan origination system. 

2. The computer implemented method for automated 
processing a mortgage loan of claim 1 comprising the 
additional act of the automatic compliance engine monitor- 
ing completion of the plurality of tasks whereby a report of 
completion of all required tasks can be generated. 

3. The computer implemented method for automated 
processing of a mortgage loan of claim 1 comprising the 
additional act of the automatic compliance engine authen- 
ticating a person submitting the request to process a mort- 
gage loan. 

4. The computer implemented method for automated 
processing of a mortgage loan of claim 1 wherein the 
plurality of tasks required to process the mortgage loan are 
based upon mortgage loan related laws and regulations 
comprising Federal, State, local and professional regulations 
and requirements and implementing instructions relating to 
mortgage loan processing. 

5. The computer implemented method for automated 
processing of a mortgage loan of claim 1 wherein the client 
loan origination system communicates with the automatic 
compliance engine using an XML format according to an 
application programming interface (API) controlled by the 
automatic compliance engine. 



6. The computer implemented method for automated 
processing of a mortgage loan of claim 1 wherein the client 
loan origination system communicates with the automatic 
compliance engine using a web page developed for use with 
the automatic compliance engine. 

7. An apparatus for automated processing of a mortgage 
loan comprising: 

an automatic compliance engine having logic mecha- 
nisms programmed to generate a plurality of tasks, the 
tasks comprising actions required to process the mort- 
gage loan, including tasks required by applicable fed- 
eral or state law; 

the automatic compliance engine coupled electronically 
to a client loan application system; 

the automatic compliance engine having communications 
devices for receiving a request to process a mortgage 
loan from the client loan application system; and 

the automatic compliance engine having additional logic- 
mechanisms programmed to electronically distribute 
one or more of the tasks to the client loan application 
system. 

8. The apparatus of claim 7 further comprising electronic 
logic devices in the compliance engine programmed to 
monitor completion of the plurality of tasks and to generate 
a report of completion of all required tasks. 

9. The apparatus of claim 7 wherein the compliance 
engine communicates with the client loan application system 
using an XMI, format according to an API controlled by the 
compliance engine. 

10. The apparatus of claim 7 wherein the plurality of tasks 
generated by the compliance engine which are required to 
process the mortgage loan are based upon mortgage loan 
related laws and regulations comprising Federal, State, local 
and professional regulations and requirements and imple- 
menting instructions relating to mortgage loan processing. 

11. An apparatus for automated processing of a mortgage 
loan comprising: 

means for receiving a request to process a mortgage loan 
from a client loan application system; 

means, coupled to the means for receiving a request to 
process a mortgage loan from a client loan application 
system, for generating a plurality of tasks, the tasks 
comprising actions required to process the mortgage 
loan, including tasks required by applicable federal or 
state law; and 

means, coupled to the means for generating a plurality of 
tasks required to process the mortgage loan, for elec- 
tronically distributing one or more of the plurality of 
tasks to the client loan application system. 

12. In a network having a user node including a browser 
program coupled to said network, said user node under the 
control of a client loan application system for providing 
requests for information and providing mortgage loan appli- 
cation related commands on said network, a network node 
comprising: 

a mortgage loan processing server node responsive to a 
request from said user node to process a mortgage loan, 
whereby said mortgage loan processing server node 
provides a first mechanism for generating a plurality of 
tasks, the tasks comprising actions required to process 
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the mortgage loan, including tasks required by appli- 
cable federal or state law; and provides a second 
mechanism coupled to the first mechanism, for distrib- 
uting one or more of the plurality of tasks to the user 

13. The network node of claim 12 wherein the mortgage 
loan processing server node provides a third mechanism to 
electronically communicate with the user node using an 
XML format for an API controlled by the mortgage loan 
processing server node. 

14. The network node of claim 12 wherein the actions 
required to process the mortgage loan are based upon 
mortgage loan related laws and regulations comprising 
Federal, State, local and professional regulations and 
requirements and implementing instructions relating to loan 
processing. 

15. A computer program product stored on a computed 
useable medium, comprising; 

a first computer readable program mechanism for receiv- 
ing a request to process a mortgage loan from a client 
loan application system; 

a second computer readable program mechanism for 
generating a plurality of tasks, the plurality of tasks 



comprising actions required to process the mortgage 
loan, including tasks required by applicable federal or 
state law; and 

a third computer readable code mechanism for distribut- 
ing one or more of the plurality of tasks to the client 
loan application system. 

16. The computer program product of claim 15 compris- 
ing a fourth computer readable code mechanism for moni- 
toring completion of the plurality of tasks whereby a report 
of completion of all required tasks can be generated. 

17. The computer program product of claim 15 wherein 
the plurality of tasks required to process the mortgage loan 
are based upon loan related laws and regulations comprising 
federal, State, local and professional regulations and 
requirements and implementing instructions relating to 
mortgage loan processing. 

18. The computer program product of claim 15 wherein 
the communications with the client loan application com- 
prises messages containing data in XML format. 



